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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. 
z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also 
known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP 
connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 

The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E- 
UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication. 

The Radio Access Network functionality is documented only to the extent necessary to describe the overall system. 
TS 36.300 [5] contains the overall description of the Evolved Universal Terrestrial Radio Access (E-UTRA) and 
Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 

ITU-T Recommendation 1.130 [3] describes a three-stage method for characterisation of telecommunication services, 
and ITU-T Recommendation Q.65 [4] defines Stage 2 of the method. 

TS 23.402 [2] is a companion specification to this specification. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

MME Pool Area: An MME Pool Area is defined as an area within which a UE may be served without need to change 
the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel. MME Pool 
Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other. 

Serving GW Service Area: A Serving GW Service Area is defined as an area within which a UE may be served 
without need to change the Serving GW. A Serving GW Service Area is served by one or more Serving GWs in 
parallel. Serving GW Service Areas are a collection of complete Tracking Areas. Serving GW Service Areas may 
overlap each other. 

PDN Connection: The association between a UE represented by one IPv4 address and/or one IPv6 prefix and a PDN 
represented by an APN. 

Default Bearer: The EPS bearer which is first established for a new PDN connection and remains established 
throughout the lifetime of the PDN connection. 

Default APN: A Default APN is defined as the APN which is marked as default in the subscription data and used 
during the Attach procedure and the UE requested PDN connectivity procedure when no APN is provided by the UE. 

Emergency attached UE: A UE which only has bearer(s) related to emergency bearer service. 

NOTE: The above term is equivalent to the term "attached for emergency bearer services" as specified in 3GPP 
TS 24.301 [46]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AF Application Function 

ARP Allocation and Retention Priority 

AMBR Aggregate Maximum Bit Rate 

CBC Cell Broadcast Centre 

CBE Cell Broadcast Entity 

CSG Closed Subscriber Group 

CSG ID Closed Subscriber Group Identity 

DeNB Donor eNode B 

DL TFT DownLink Traffic Flow Template 

ECGI E-UTRAN Cell Global Identifier 

ECM EPS Connection Management 

ECN Explicit Congestion Notification 

EMM EPS Mobility Management 

eNB evolved Node B 

EPC Evolved Packet Core 

EPS Evolved Packet System 

E-RAB E-UTRAN Radio Access Bearer 

E-UTRAN Evolved Universal Terrestrial Radio Access Network 

GBR Guaranteed Bit Rate 

GUMMEI Globally Unique MME Identifier 

GUTI Globally Unique Temporary Identity 

GW Gateway 

HeNB Home eNode B 

HeNB GW Home eNode B Gateway 
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HFN Hyper Frame Number 

ISR Idle mode Signalling Reduction 

OFCS Offline Charging System 

LBI Linked EPS Bearer Id 

L-GW Local GateWay 

LIPA Local IP Access 

MBR Maximum Bit Rate 

MME Mobility Management Entity 

MMEC MME Code 

MTC Machine-Type Communications 

M-TMSI M-Temporary Mobile Subscriber Identity 

OMC-ID Operation and Maintenance Centre Identity 

P-GW PDN Gateway 

PDCP Packet Data Convergence Protocol 

PMIP Proxy Mobile IP 

PSAP Public Safety Answering Point 

PTI Procedure Transaction Id 

QCI QoS Class Identifier 

RFSP RAT/Frequency Selection Priority 

RN Relay Node 

S-GW Serving Gateway 

S-TMSI S-Temporary Mobile Subscriber Identity 

SDF Service Data Flow 

SIPTO Selected IP Traffic Offload 

TAC Tracking Area Code 

TAD Traffic Aggregate Description 

TAI Tracking Area Identity 

TAU Tracking Area Update 

TI Transaction Identifier 

TIN Temporary Identity used in Next update 

URRP-MME UE Reachability Request Parameter for MME 

UL TFT UpLink Traffic Flow Template 

ULR-Flags Update Location Request Flags 
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4 Architecture model and concepts 

4.1 General concepts 

Local breakout of IP traffic via the visited PLMN is supported, when network policies and user subscription allow it. 
Local breakout may be combined with support for multiple simultaneous PDN connections, described in clause 5.10. 

4.2 Architecture reference model 
4.2.1 Non-roaming architecture 
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Figure 4.2.1-1 : Non-roaming architecture for 3GPP accesses 
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Figure 4.2.1-2: Non-roaming architecture for 3GPP accesses. Single gateway configuration option 

NOTE 1 : Also in this configuration option, S5 can be used between non collocated Serving Gateway and PDN 
Gateway. 

NOTE 2: Additional interfaces for 2G/3G access are shown in TS 23.060 [7]. 
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4.2.2 Roaming architecture 



HPLMN 




Figure 4.2.2-1 : Roaming architecture for 3GPP accesses. IHome routed traffic 

NOTE 1: Additional interfaces/reference points for 2G/3G accesses are documented in TS 23.060 [7]. 

The figures 4.2.2-2 and 4.2.2-3 represent the Roaming with local breakout case with Apphcation Function (AF) in the 
Home Network and in the Visited Network respectively. The concurrent use of AF's in the home network and AF's in 
the visited network is not excluded. 
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HPLMN 



HSS 



H-PCRF 




Figure 4.2.2-2: Roaming archiitecture for local breakout, with home operator's application functions 

only 

NOTE 2: See TS 23.203 [6] for the role of and functions related to Home and Visited PCRF and S9/Rx reference 
points. 

NOTE 3: In figure 4.2.2-2, the control plane signalling and the user plane for accessing to Home Operator's 
services traverse over the SGi reference point via the Visited Operator's PDN. 
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HPLMN 




Figure 4.2.2-3: Roaming architecture for local breakout, with visited operator's application functions 

only 

4.2.3 Reference points 

Sl-MME: Reference point for the control plane protocol between E-UTRAN and MME. 

Sl-U: Reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling and inter 
eNodeB path switching during handover. 

S3: It enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or 

active state. 

S4: It provides related control and mobility support between GPRS Core and the 3GPP Anchor function of 

Serving GW. In addition, if Direct Tunnel is not established, it provides the user plane tunnelling. 

S5: It provides user plane tunnelling and tunnel management between Serving GW and PDN GW. It is used 

for Serving GW relocation due to UE mobility and if the Serving GW needs to connect to a non- 
collocated PDN GW for the required PDN connectivity. 

S6a: It enables transfer of subscription and authentication data for authenticating/authorizing user access to the 

evolved system (AAA interface) between MME and HSS. 

Gx: It provides transfer of (QoS) policy and charging rules from PCRF to Policy and Charging Enforcement 

Function (PCEF) in the PDN GW. 

S8: Inter-PLMN reference point providing user and control plane between the Serving GW in the VPLMN 

and the PDN GW in the HPLMN. S8 is the inter PLMN variant of S5. 

S9: It provides transfer of (QoS) policy and charging control information between the Home PCRF and the 

Visited PCRF in order to support local breakout function. 

SIO: Reference point between MMEs for MME relocation and MME to MME information transfer. 

Sll: Reference point between MME and Serving GW. 
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S12: Reference point between UTRAN and Serving GW for user plane tunnelling when Direct Tunnel is 

established. It is based on the lu-u/Gn-u reference point using the GTP-U protocol as defined between 
SGSN and UTRAN or respectively between SGSN and GGSN. Usage of S12 is an operator configuration 
option. 

S13: It enables UE identity check procedure between MME and EIR. 

SGi: It is the reference point between the PDN GW and the packet data network. Packet data network may be 

an operator external public or private packet data network or an intra operator packet data network, e.g. 
for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses. 

Rx: The Rx reference point resides between the AF and the PCRF in the TS 23.203 [6]. 

SBc: Reference point between CBC and MME for warning message delivery and control functions. 

When data forwarding is used as part of mobility procedures different user plane routes may be used based on the 
network configuration (e.g. direct or indirect data forwarding). These routes can be between eNodeB and RNC, eNodeB 
and SGSN, RNC and S-GW or between S-GW and SGSN. Explicit reference points are not defined for these routes. 

Protocol assumption: 

The S 1 -U is based on GTP-U protocol; 

The S3 is based on GTP protocol; 

The S4 is based on GTP protocol; 

- The S5 is based on GTP protocol. PMIP variant of S5 is described in TS 23.402 [2]; 

- The S8 is based on GTP protocol. PMIP variant of S8 is described in TS 23.402 [2]. 

S3, S4, S5, S8, SIO and SI 1 interfaces are designed to manage EPS bearers as defined in clause 4.7.2. 
NOTE: Redundancy support on reference points S5 and SB should be taken into account. 



4.2.4 Warning System architecture 




LTE-Uu 



S1-MME 



SBc 



Figure 4.2.4-1 : Warning System Architecture for 3GPP Accesses 

NOTE: The CBE and the interface between CBE and CBC are out of scope of 3GPP specifications. 

4.3 Higin level functions 
4.3.1 General 

The following list gives the logical functions performed within this system. Several functional groupings (meta 
functions) are defined and each encompasses a number of individual functions: 

Network Access Control Functions. 

Packet Routing and Transfer Functions. 

Mobility Management Functions. 

- Security Functions. 
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Radio Resource Management Functions. 
Network Management Functions. 

4.3.2 Network access control functions 

4.3.2.1 General 

Network access is the means by which a user is connected to the evolved packet core system. 

4.3.2.2 Network/Access network selection 

It is the means by which a UE selects a PLMN/ Access network from which to gain IP connectivity. The network/access 
network selection procedure varies for different access technologies. For 3GPP access networks, the network selection 
principles are described in TS 23.122 [10]. For 3GPP access networks, the access network selection procedures are 
described in TS 36.300 [5], TS 43.022 [II] and TS 25.304 [12]. 

Architectural impacts stemming from support for network/access network selection procedures for non-3GPP access 
and between 3GPP access and non-3GPP accesses are described in TS 23.402 [2]. 

4.3.2.3 Authentication and authorisation function 

This function performs the identification and authentication of the service requester, and the validation of the service 
request type to ensure that the user is authorised to use the particular network services. The authentication function is 
performed in association with the Mobility Management functions. 

4.3.2.4 Admission control function 

The purpose of admission control is to determine if the requested resources are available, and then reserve those 
resources. 

4.3.2.5 Policy and Charging Enforcement Function 

This includes all the functionality of PCEF as defined by TS 23.203 [6]. The PCEF encompasses service data flow 
detection, policy enforcement and flow based charging functionalities as defined in TS 23.203 [6]. 

4.3.2.6 Lawful Interception 

Lawful interception is the action, performed by a network operator / access provider / service provider, of making 
available certain information and providing that information to a law enforcement monitoring facility. 

4.3.3 Packet routing and transfer functions 

4.3.3.1 General 

A route is an ordered list of nodes used for the transfer of packets within and between the PLMN(s). Each route consists 
of the originating node, zero or more relay nodes and the destination node. Routing is the process of determining and 
using, in accordance with a set of rules, the route for transmission of a message within and between the PLMN(s). 

The EPS is an IP network and uses the standard routing and transport mechanisms of the underlying IP network. 

The Maximum Transfer Unit (MTU) size considerations in clause 9.3 of 3GPP TS 23.060 [7] are also applicable to 
EPS. 

4.3.3.2 IP header compression function 

The IP header compression function optimises use of radio capacity by IP header compression mechanisms. 
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4.3.3.3 Packet screening function 

The packet screening function provides the network with the capabihty to check that the UE is using the exact IPv4- 
Address and/or IPv6-Prefix that was assigned to the UE. 

4.3.3.4 IP Multicast Forwarding between a network accessed by LIPA and a UE 

The Home eNodeB L-GW should support IP forwarding of packets to muhicast groups between the UE and the 
network accessed by LIPA. 

4.3.4 Security functions 

The security functions are described in clause 5.3.10. 

4.3.5 Mobility management functions 

4.3.5.1 General 

The mobility management functions are used to keep track of the current location of a UE. 

4.3.5.2 Reachability Management for UE In ECM-IDLE state 

The location of a UE in ECM-IDLE state is known by the network on a Tracking Area List granularity. A UE in ECM- 
IDLE state is paged in all cells of the Tracking Areas in which it is currently registered. The UE may be registered in 
multiple Tracking Areas. All the tracking areas in a Tracking Area List to which a UE is registered are served by the 
same serving MME. 

An EMM-REGISTERED UE performs periodic Tracking Area Updates with the network after the expiry of the 
periodic TAU timer. 

The MME may allocate long periodic TAU timer value to the UE according to clause 4.3. 17.3. 

If the UE is out of E-UTRAN coverage (including the cases when the UE is camped on GERAN/UTRAN cells) when 
its periodic TAU timer expires, the UE shall: 

- if ISR is activated, start the E-UTRAN Deactivate ISR timer. After the E-UTRAN Deactivate ISR timer expires 
the UE shall deactivate ISR by setting its TIN to "P-TMSI". 

if ISR is activated and the UE is camping on a GERAN/UTRAN cell (or returns to coverage in 
GERAN/UTRAN) and the UE is EPS/IMSI attached, perform a LAU procedure in NMO II/III or a combined 
RA/LA update procedure in NMO I. 

when EMM-REGISTERED, perform a Tracking Area Update when it next returns to E-UTRAN coverage. 

If the UE is camped on an E-UTRAN cell or is in ECM-CONNECTED state when the UE's periodic RAU timer 
expires, the UE shall: 

- if ISR is activated, start the GERAN/UTRAN Deactivate ISR timer. After the GERAN/UTRAN Deactivate ISR 
timer expires the UE shall deactivate ISR by setting its TIN to "GUTI". 

perform a Routing Area Update when it next returns to GERAN/UTRAN coverage. 

If the UE is EPS attached only and either camps on an E UTRAN cell or is in ECM CONNECTED state when the UE's 
periodic LAU timer expires, the UE shall perform a Location Area Update procedure in NMO II/III or combined 
RA/LA update in NMO I when it next returns to GERAN/UTRAN coverage. 

The E-UTRAN Deactivate ISR timer is stopped when the UE performs a successful Tracking Area Update or combined 
TA/LA Update; and the GERAN/UTRAN Deactivate ISR timer is stopped when the UE performs a successful Routing 
Area Update or combined RA/LA Update. 

Expiry of the periodic TAU timer, or, the periodic RAU timer, or, the periodic LAU timer shall not cause the UE to 
change RAT. 
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The UE's periodic TAU timer is restarted from its initial value whenever the UE enters ECM-IDLE mode and when the 
UE leaves the E-UTRAN connection due to handover to GERAN/UTRAN. UTRAN RRC state transitions and GERAN 
GPRS STANDBY/READY state transitions shall have no other impact on the periodic TAU timer. 

E-UTRAN RRC state transitions shall have no impact on the periodic RAU timer or periodic LAU timer except that 
handover from GERAN/UTRAN to E-UTRAN shall cause the periodic RAU timer to be started from its initial value. 

Handover from E UTRAN to UTRAN/GERAN shall cause the periodic TAU timer to be started from its initial value. 

Typically, the MME runs a mobile reachable timer with a similar value to the UE's periodic TAU timer. If this timer 
expires in the MME, the MME can deduce that the UE is 'out of coverage' at that moment. However, the MME does not 
know for how long the UE has been out of coverage, so, the MME shall not immediately delete the UE's bearers. 
Instead the MME should clear the PPF flag in the MME and start an Implicit Detach timer, with a relatively large value 
and if ISR is activated, at least slightly larger than the UE's E-UTRAN Deactivate ISR timer. With the PPF clear, the 
MME does not page the UE in E-UTRAN coverage and shall send a Downlink Data Notification Reject message to the 
Serving GW when receiving a Downlink Data Notification message from the Serving GW. If this Implicit Detach timer 
expires before the UE contacts the network, then the MME can deduce that the UE has been 'out of coverage' for a long 
period of time and implicitly detach the UE as described in clause 5.3.8.3 "MME-initiated Detach procedure". 

NOTE 1: The SGSN has similar functionahty as the MME. 

NOTE 2: Alternative MME implementations are permitted, however, the externally visible MME behaviour should 
conform to the above description. 

4.3.5.3 Tracking Area list management 

Tracking Area list management comprises the functions to allocate and reallocate a Tracking Area Identity list to the 
UE. All the tracking areas in a Tracking Area List to which a UE is registered are served by the same serving MME. 

The "tracking area list concept" is used with E-UTRAN. 'With this concept, when the UE registers with the network, the 
MME allocates a set (a "list") of tracking areas to the UE. By making the centre of this set of tracking areas close to the 
UE's current location, the chance of a UE rapidly making another tracking area update can be reduced. 

NOTE: This TAI list functionahty is different to the SGSN behaviour in GERAN and UTRAN systems. In 
GERAN/UTRAN the UE is only registered in one Routeing Area at a time. 

4.3.5.4 Inter-eNodeB mobility anchor function 

The Inter-eNodeB Mobility Anchor is the functional entity that anchors the user plane for E-UTRAN mobility. 

4.3.5.5 lnter-3GPP mobility anchor function 

The Inter-3GPP Mobility Anchor is the functional entity that anchors the user plane for mobility between 3GPP 2G/3G 
access systems and the E-UTRA access system. 

4.3.5.6 Idle mode signalling reduction function 

The Idle mode Signalling Reduction (ISR) function provides a mechanism to limit signalling during inter-RAT cell- 
reselection in idle mode (ECM-IDLE, PMM-IDLE, GPRS STANDBY states). 

NOTE 1 : The Idle mode Signalling Reduction function is mandatory for E-UTRAN UEs that support GERAN 
and/or UTRAN and optional for core network. The UE's ISR capability in the UE Core Network 
Capability element is for test purpose. 

The MME/SGSN activates ISR only if the Serving GW supports the ISR. How MME/SGSN determines a Serving GW 
supports ISR is implementation dependent. 

ISR shall be activated by decision of the CN nodes and shall be explicitly signalled to the UE as "ISR activated" in the 
RAU and TAU Accept messages. The UE may have valid MM parameters both from MME and from SGSN. The 
"Temporary Identity used in Next update" (TIN) is a parameter of the UE's MM context, which identifies the UE 
identity that the UE shall indicate in the next RAU Request, TAU Request or Attach Request message. The TIN also 
identifies the status of ISR activation in the UE. 
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The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE shall set the TIN when 
receiving an Attach Accept, a TAU Accept or RAU Accept message according to the rules in table 4.3.5.6-1. 

Table 4.3.5.6-1 : Setting of the TIN 



Message received by UE 


Current TIN value stored by 
UE 


TIN value to be set by the 

UE when receiving 

message 


Attach Accept via E-UTRAN 
(never indicates "ISR Activated") 


Any value 


GUTI 


Attach Accept via 

GERAN/UTRAN 

(never indicates "ISR Activated") 


Any value 


P-TMSI 


TAU Accept 
not indicating "ISR Activated" 


Any value 


GUTI 


TAU Accept 
indicating "ISR Activated" 


GUTI 
P-TMSI or RAT-related TMSI 


GUTI 
RAT-related TMSI 


RAU Accept 
not indicating "ISR Activated" 


Any value 


P-TMSI 


RAU Accept 
indicating "ISR Activated" 


P-TMSI 
GUTI or RAT-related TMSI 


P-TMSI 
RAT-related TMSI 



When "ISR Activated" is indicated by the RAU/TAU Accept message but the UE shall not set the TIN to "RAT-related 
TMSI" is a special situation. Here the UE has deactivated ISR due to special situation handling. By maintaining the old 
TIN value the UE remembers to use the RAT specific TMSI indicated by the TIN when updating with the CN node of 
the other RAT. 

Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all 
registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the 
TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) shall remain registered 
with the network and shall remain valid in the UE. 

Table 4.3.5.6-2: Temporary UE Identity that the UE shall indicate in Attach Request and TAU/RAU 
Request (as "old GUTI" or as "old P-TMSI/RAI" information element) 



IVIessage to be sent by 
UE 


TIN value: P-TMSI 


TIN value: GUTI 


TIN value: RAT-related 
TMSI 


TAU Request 


GUTI mapped from 
P-TMSI/RAI 


GUTI 


GUTI 


RAU Request 


P-TMSI/RAI 


P-TMSI/RAI mapped from 
GUTI 


P-TMSI/RAI 


Attach Request via E- 
UTRAN 


GUTI mapped from 
P-TMSI/RAI 


GUTI 


GUTI 


Attach Request via 
GERAN/UTRAN 


P-TMSI/RAI 


P-TMSI/RAI mapped from 
GUTI 


P-TMSI/RAI 



Table 4.3.5.6-2 shows which temporary identity the UE shall indicate in a Tracking or Routing Area Update Request or 
in an Attach Request message, when the UE stores these as valid parameters. 

Situations may occur that cause unsynchronized state information in the UE, MME and SGSN. Such special situations 
trigger a deactivation of ISR locally in the UE. 

The UE shall deactivate ISR locally by setting its TIN to the temporary identity of the currently used RAT in following 
special situations: 

Modification of any EPS bearer context or PDP context which was activated before the ISR is activated in the 
UE; 

- At the time when the UE moves from E-UTRAN to GERAN/UTRAN or moves from GERAN/UTRAN to 
E-UTRAN by means other than PSHO, if any EPS bearer context or PDP context activated after the ISR was 
activated in the UE exists; 

After updating either MME or SGSN about the change of the UE specific DRX parameters to guarantee that the 
other CN node is also updated; 
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After updating either MME or SGSN about the change of the UE Core Network Capabilities to guarantee that 
the other CN node is also updated; 

- E-UTRAN selection by a UTR AN -connected UE (e.g. when in URA_PCH to release lu on UTRAN side); 

After a LAU procedure if the UE has CS fallback and/or SMS over SGs activated. 

For a UE that is IMS registered for voice, then after that UE moves from a Registration Area that supports IMS 
voice over PS sessions (see 4.3.5.8 for more information) to one that does not, and vice versa. It shall be 
possible, e.g. using Device Management or initial provisoning, to configure the UE to apply/not apply this 
particular exception. 

NOTE 2: A UE moving between Registration Areas that both support IMS voice over PS sessions, or, both that do 
not support IMS voice over PS sessions, is unaffected by the above. 

The UE shall deactivate ISR locally by setting its TIN to the temporary identity of the RAT that is still available to the 
UE in following special situations: 

After the RAT-specific Deactivate ISR timer expires, e.g. because the coverage of that RAT is lost or the RAT is 
no more selected by the UE (this may result also in implicit detach by SGSN or MME). 

ISR shall be deactivated in the UE by the CN node using normal update signalling, i.e. by omitting the signalling of 
"ISR Activated", in following special situations: 

CN node change resulting in context transfer between the same type of CN nodes (SGSN to SGSN or MME to 
MME); 

Serving GW change; 

When the UE only has bearers related to emergency bearer service. 

4.3.5.7 Mobility Restrictions 

Mobility Restrictions comprises the functions for restrictions to mobility handling of a UE in E-UTRAN access. The 
Mobility Restriction functionality is provided by the UE, the radio access network and the core network. 

Mobility Restriction functionality in state ECM-IDLE is executed in UE based on information received from the core 
network. Mobility Restriction functionality in state ECM-CONNECTED is executed in the radio network and the core 
network. 

In state ECM-CONNECTED, the core network provides the radio network with a Handover Restriction List. The 
Handover Restriction List specifies roaming, area and access restrictions. 

4.3.5.8 IMS voice over PS Session Supported Indication 

The serving PLMN shall send an indication toward the UE during the Attach procedure and Tracking Area Update 
procedures if an IMS voice over PS session is supported. The serving PLMN uses this indicator to indicate to the UE 
whether it can expect a successful IMS voice over PS session. A UE with "IMS voice over PS" voice capability should 
take this indication into account when establishing voice over PS sessions (as specified in TS 23.221 [27]) as well as 
when determining whether to deactivate the special handling of ISR locally (as detailed in clause 4.3.5.6). 

The serving PLMN provides this indication based e.g. on local policy, HPLMN, the SRVCC capability of the network 
and UE and/or extends of E-UTRAN/UTRAN coverage. The serving PLMN shall indicate to the UE that the UE can 
expect a successful IMS voice over PS session only if the MME is configured to know that the serving PLMN has a 
roaming agreement for IMS voice with the HPLMN of the UE. This indication is per TAI list. 

On request by the HSS, the MME shall indicate the following: 

whether or not an IMS voice over PS Session is supported in the TA(s) that are registered for the UE ("IMS 
voice over PS Session Supported Indication"), together with the time of the last radio contact with the UE; and 

the current RAT type. 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 26 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

NOTE: In order to support routing of incoming IMS voice calls to the correct domain (PS or CS), the network- 
based T-ADS (see TS 23.292 [60] and TS 23.221 [27]) requires that there is homogeneous support/non- 
support of IMS voice over PS session for all registered TAs of the UE. 

4.3.5.9 Voice domain preference and UE's usage setting 

If the UE supports CS fallback, or the UE is configured to support IMS voice, or both, the UE shall include the 
information element "Voice domain preference and UE's usage setting" in Attach Request, Tracking Area Update 
Request and Routing Area Update Request messages. The purpose of this information element is to signal to the 
network the UE's usage setting and voice domain preference for E-UTRAN. The UE's usage setting indicates whether 
the UE behaves in a voice centric or data centric way (as defined in TS 23.221 [27]). The voice domain preference for 
E-UTRAN indicates whether the UE is configured as CS Voice only, CS Voice preferred and IMS PS Voice as 
secondary, IMS PS Voice preferred and CS Voice as secondary, or IMS PS Voice only (as defined in TS 23.221 [27]). 

NOTE: Depending on operator's configuration, the UE's usage setting and voice domain preference for 
E-UTRAN can be used by the network to choose the RFSP Index in use (see clause 4.3.6). As an 
example, this enables the enforcement of selective idle mode camping over GERAN/UTRAN for voice 
centric UEs relying on CS Fallback for voice support in E-UTRAN. 

4.3.6 Radio Resource Management functions 

Radio resource management functions are concerned with the allocation and maintenance of radio communication 
paths, and are performed by the radio access network. The RRM strategy in E-UTRAN may be based on user specific 
information. 

To support radio resource management in E-UTRAN the MME provides the parameter 'Index to RAT/Frequency 
Selection Priority' (RFSP Index) to an eNodeB across SI. The RFSP Index is mapped by the eNodeB to locally defined 
configuration in order to apply specific RRM strategies. The RFSP Index is UE specific and applies to all the Radio 
Bearers. Examples of how this parameter may be used by the E-UTRAN: 

to derive UE specific cell reselection priorities to control idle mode camping. 

to decide on redirecting active mode UEs to different frequency layers or RATs. 

The MME receives the subscribed RFSP Index from the HSS (e.g., during the Attach procedure). For non-roaming 
subscribers the MME chooses the RFSP Index in use according to one of the following procedures, depending on 
operator's configuration: 

the RFSP Index in use is identical to the subscribed RFSP Index, or 

the MME chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator's 
policies and the UE related context information available at the MME, including UE's usage setting and voice 
domain preference for E-UTRAN, if received during Attach and Tracking Area Update procedures (see 
clause 4.3.5.9). 

NOTE: One example of how the MME can use the "UE voice capabilities and settings" is to select an RFSP value 
that enforces idle mode camping on 2G/3G for a UE acting in a "Voice centric" way and provisioned with 
"CS Voice preferred, IMS Voice as secondary", in order to minimize the occurrancy of RAT changes. 
Another example is the selection of an RFSP value that prevents idle mode camping on 2G for a UE 
provisioned with "IMS PS voice preferred, CS Voice as secondary" if other RATs supporting IMS Voice 
are available, as the UE would in such case always select the CS domain for its voice calls. 

For roaming subscribers the MME may alternatively choose the RFSP Index in use based on the visited network policy, 
but can take input from the HPLMN into account (e.g., an RFSP Index value pre-configured per HPLMN, or a single 
RFSP Index value to be used for all roamers independent of the HPLMN). 

The MME forwards the RFSP Index in use to the eNodeB across S 1 . The RFSP Index in use is also forwarded from 
source eNodeB to target eNodeB when X2 is used for intra-E-UTRAN handover. 

The MME stores the subscribed RFSP Index value received from the HSS and the RFSP Index value in use. During the 
Tracking Area Update procedure, the MME may update the RFSP Index value in use (e.g. the MME may need to 
update the RFSP Index value in use if the UE related context information in the MME has changed). When the RFSP 
Index value in use is changed, the MME immediately provides the updated RFSP Index value in use to eNodeB by 
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modifying an existing UE context or by establishing an new UE context in the eNodeB or by being configured to 
include the updated RFSP Index value in use in the DOWNLINK NAS TRANSPORT message if the user plane 
establishment is not needed. During inter-MME mobility procedures, the source MME forwards both RFSP Index 
values to the target MME. The target MME may replace the received RFSP Index value in use with a new RFSP Index 
value in use that is based on the operator's policies and the UE related context information available at the target MME. 

The SI messages that transfer the RFSP Index to the eNodeB are specified in TS 36.413 [36]. Refer to TS 36.300 [5] 
for further information on E-UTRAN. 

4.3.7 Network management functions 

4.3.7.1 General 

Network management functions provide mechanisms to support O&M functions related to the Evolved Packet System. 

4.3.7.2 Load balancing between MMEs 

The MME Load Balancing functionality permits UEs that are entering into an MME Pool Area to be directed to an 
appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting a Weight Factor 
for each MME, such that the probability of the eNodeB selecting an MME is proportional to its Weight Factor. The 
Weight Factor is typically set according to the capacity of an MME node relative to other MME nodes. The Weight 
Factor is sent from the MME to the eNodeB via Sl-AP messages (see TS 36.413 [36]). If a HeNB GW is deployed, the 
Weight Factor is sent from the MME to the HeNB GW. 

NOTE 1 : An operator may decide to change the Weight Factor after the establishment of S 1 -MME connectivity as 
a result of changes in the MME capacities. E.g., a newly installed MME may be given a very much higher 
Weight Factor for an initial period of time making it faster to increase its load. 

NOTE 2: It is intended that the Weight Factor is NOT changed frequently, e.g. in a mature network, changes on a 
monthly basis could be anticipated, e.g. due to the addition of RAN or CN nodes. 

4.3.7.3 Load re-balancing between IVIIVIEs 

The MME Load Re-balancing functionality permits UEs that are registered on an MME (within an MME Pool Area) to 
be moved to another MME. 

NOTE 1 : An example use for the MME Load Re-balancing function is for the Oh-M related removal of one MME 
from an MME Pool Area. 

NOTE 2: Typically, this procedure should not be used when the MME becomes overloaded because the Load 

Balancing function should have ensured that the other MMEs in the pool area are similarly overloaded. 

The eNodeBs may have their Load Balancing parameters adjusted beforehand (e.g. the Weight Factor is set to zero if all 
subscribers are to be removed from the MME, which will route new entrants to the pool area into other MMEs). 

In addition the MME may off-load a cross-section of its subscribers with minimal impacts on the network and users 
(e.g. the MME should avoid offloading only the low activity users while retaining the high activity subscribers. Gradual 
rather than sudden off-loading should be performed as a sudden re-balance of large number of subscribers could 
overload other MMEs in the pool. With minimal impact on network and the user's experience, the subscribers should be 
off-loaded as soon as possible). The load re-balancing can off-load part of or all the subscribers. 

To off-load ECM-CONNECTED mode UEs, the MME initiates the SI Release procedure with release cause "load 
balancing TAU required" (clause 5.3.5). The SI and RRC connections are released and the UE initiates a TAU but 
provides neither the S-TMSI nor the GUMMEI to eNodeB in the RRC establishment. 

The MME should not release all S 1 connections which are selected to be released immediately when offloading is 
initiated. The MME may wait until the S 1 Release is performed due to inactivity. When the MME is to be offloaded 
completely the MME can enforce an S I Release for all remaining UEs that were not offloaded by normal TAU 
procedures or by S 1 releases caused by inactivity. 

To off-load UEs which perform TA Updates or Attaches initiated in ECM-IDLE mode, the MME completes that 
procedure and the procedure ends with the MME releasing SI with release cause "load balancing TAU required". The 
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S 1 and RRC connections are released and the UE initiates a TAU but provides neither the S-TMSI nor the GUMMEI to 
eNodeB in the RRC estabHshment. 

When the UE provides neither the S-TMSI nor the GUMMEI in the RRC establishment, the eNodeB should select an 
MME based on the Weight Factors of the MMEs in the pool. 

To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request and 
become ECM-CONNECTED, the MME first pages UE to bring it to ECM-CONNECTED state. If paging the UE fails 
and ISR is activated, the MME should adjust its paging retransmission strategy (e.g. limit the number of short spaced 
retransmissions) to take into account the fact that the UE might be in GERAN/UTRAN coverage. 

4.3.7.4 MME control of overload 

4.3.7.4.1 General 

The MME shall contain mechanisms for avoiding and handling overload situations. These can include the use of NAS 
signalling to reject NAS requests from UEs. 

In addition, under unusual circumstances, the MME shall restrict the load that its eNodeBs are generating on it if it is 
configured to enable the overload restriction. This can be achieved by the MME invoking the S 1 interface overload 
procedure (see TS 36.300 [5] and TS 36.413 [36]) to a proportion of the eNodeB's with which the MME has SI 
interface connections. To reflect the amount of load that the MME wishes to reduce, the MME can adjust the proportion 
of eNodeBs which are sent SI interface OVERLOAD START message, and the content of the OVERLOAD START 
message. 

The MME should select the eNodeBs at random (so that if two MMEs within a pool area are overloaded, they do not 
both send OVERLOAD START messages to exactly the same set of eNodeBs). 

Using the OVERLOAD START message, the MME can request the eNodeB to: 

reject all RRC connection requests that are for non-emergency and non-high priority mobile originated services; 
or 

NOTE 1: This blocks PS service and service provided by MSC following an EPS/IMSI attach procedure. 

reject all new RRC connection requests for EPS Mobility Management signalling (e.g. for TA Updates) for that 
MME; or 

only permit RRC connection requests for emergency sessions and mobile terminated services for that MME. 
This blocks emergency session requests from UEs with USIMs provisioned with Access Classes 1 1 and 15 when 
they are in their HPLMN/EHPLMN and from UEs with USIMs provisioned with Access Classes 12, 13 and 14 
when they are in their home country (defined as the MCC part of the IMSI, see TS 22.01 1 [67]); or. 

NOTE 2: The MME can restrict the number of responses to paging by not sending paging messages for a 

proportion of the events that initiate paging. As part of this process, the MME can provide preference for 
paging UEs with Emergency Bearer Services. 

only permit RRC connection requests for high priority sessions and mobile terminated services for that MME. 

When rejecting an RRC connection request for overload reasons the eNodeB indicates to the UE an appropriate timer 
value that limits further RRC connection requests for a while. 

In addition, the MME can request the eNodeB to restrict the load from subcategories of UEs that its connected eNodeBs 
are generating on it. These subcategories include UEs that reselect from other PLMNs (PLMN type) and all UEs using 
low access priority for the radio access. PLMN type barring can for example be used to protect a VPLMN from an 
overload caused by the failure of one (or more) other networks in that country and accesses made from roaming 
subscribers. 

An eNodeB supports rejecting of RRC connection establishments for certain subcategories of UEs as specified in 
TS 36.331 [37] . 

If an MME invokes the S 1 interface overload procedure for a subcategory of UEs, the MME should select all eNodeBs 
with which the MME has SI interface connections. Alternatively, the selected eNodeBs may be limited to a subset of 
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the eNodeBs with which the MME has SI interface connection (e.g. particular location area or where devices of the 
targeted type are registered). 

During an overload situation the MME should attempt to maintain support for emergency bearer services. 

When the MME has recovered and wishes to increase its load for a particular subcategory, the MME sends 
OVERLOAD STOP messages to the eNodeB(s), specifying the subcategory of UEs to no longer restrict. 

Hardware and/or software failures within an MME may reduce the MME's load handling capability. Typically such 
failures should result in alarms which alert the operator/O+M system. Only if the operator/O+M system is sure that 
there is spare capacity in the rest of the pool, the operator/O+M system might use the load re-balancing procedure to 
move some load off this MME. However, extreme care is needed to ensure that this load re-balancing does not overload 
other MMEs within the pool area (or neighbouring SGSNs) as this might lead to a much wider system failure. 

In addition, to protect the network from overload the MME has the option of rejecting NAS request messages which 
include the low access priority indicator before rejecting NAS request messages without the low access priority 
indicator (see clause 4.3.7.4.2 for more information). 

4.3.7.4.1a Throttling of Downlink Data Notification Requests 

Under unusual circumstances (e.g. when the MME load exceeds an operator configured threshold), the MME may 
restrict the signalling load that its SGWs are generating on it, if configured to do so. 

The MME can reject Downlink Data Notification requests for low priority traffic for UEs in idle mode or to further 
offload the MME, the MME can request the SGWs to selectively reduce the number of Downlink Data Notification 
requests it sends for downlink low priority traffic received for UEs in idle mode according to a throttling factor and for 
a throttling delay specified in the Downlink Data Notification Ack message. 

The SGW determines whether a bearer is for low priority traffic or not on the basis of the bearer's ARP priority level 
and operator policy (i.e. operator's configuration in the SGW of the ARP priority levels to be considered as priority or 
non- priority traffic). The MME determines whether a Downlink Data Notification request is for low priority traffic or 
not on the basis of the ARP priority level that was received from the SGW and operator policy. 

During the throttling delay, the SGW drops downlink packets received on all its low priority bearers for UEs known as 
not user plane connected (i.e. the SGW context data indicates no downlink user plane TEID) served by that MME in 
proportion to the throttling factor, and sends a Downlink Data Notification message to the MME only for the non 
throttled bearers. 

The SGW resumes normal operations at the expiry of the throttling delay. The last received value of the throttling factor 
and throttling delay supersedes any previous values received from that MME. The reception of a throttling delay restarts 
the SGW timer associated with that MME. 

4.3.7.4.2 NAS level congestion control 

4.3.7.4.2.1 General 

NAS level congestion control contains the functions: "APN based congestion control" and "General NAS level Mobility 
Management control". 

The use of the APN based congestion control is for avoiding and handling of EMM and ESM signalling congestion 
associated with UEs with a particular APN. Both UEs and network shall support the functions to provide APN based 
EMM and ESM congestion control. 

The MME may detect the NAS signalling congestion associated with the APN and start and stop performing the APN 
based congestion control based on criteria such as: 

Maximum number of active EPS bearers per APN;; 

Maximum rate of EPS Bearer activations per APN;; 

One or multiple PDN GWs of an APN are not reachable or indicated congestion to the MME; 

Maximum rate of MM signalling requests associated with the devices with a particular subscribed APN; and/or 
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Setting in network management. 

The MME should not apply NAS level congestion control for Service Users (according to TS 22.153 [68]) and/or 
emergency services. 

With General NAS level Mobility Management control, the MME may also use the reject of NAS level Mobility 
Management signalling requests under general congestion conditions. 

4.3.7.4.2.2 APN based Session Management congestion control 

The MME may reject the EPS Session Management (ESM) requests from the UE (e.g. PDN Connectivity, Bearer 
Resource Allocation or Bearer Resource Modification Requests) with a Session Management back-off timer when ESM 
congestion associated with the APN is detected. If the UE provides no APN, then default APN from subscription data is 
used by the MME. 

The MME may store a Session Management back-off time when congestion control is active for an APN. The MME 
may immediately reject any subsequent request from the UE targeting to the APN before the stored Session 
Management back-off time is expired. 

NOTE: The above functionality is to diminish the performance advantage for UEs that do not support the NAS 
level back-off timer (e.g. pre-Rel-10 UEs) compared to UEs that do support it. 

Upon reception of the Session Management back-off timer in the EPS Session Management reject message, the UE 
shall take the following actions until the timer expires: 

If APN is provided in the rejected EPS Session Management Request message, the UE shall not initiate any 
Session Management procedures for the congested APN except for releasing the PDN connection (e.g. sending 
PDN Disconnection Request). The UE may inititate Session Management procedures for other APNs. 

If APN is not provided in the rejected EPS Session Management Request message, the UE shall not initiate any 
Session Management requests without APN. The UE may initiate Session Management procedures for specific 
APN. 

Cell/TA/PLMN/RAT change do not stop the Session Magement back-off timer. 

The UE is allowed to initiate the Session Management procedures for Service Users, emergency services and 
mobile terminated services even when the Session Management back-off timer is running. 

The UE shall support a separate Session Management back-off timer for every APN that the UE may activate. 

To avoid that large amounts of UEs initiate deferred requests (almost) simultaneously, the MME should select the 
Session Management back-off timer value so that deferred requests are not synchronized. 

The APN based Session Management congestion control is applicable to the NAS ESM signalling initiated from the UE 
in the control plane. The Session Management congestion control does not prevent the UE to send and receive data or 
initiate Service Request procedures for activating user plane bearers towards the APN(s) that are under ESM congestion 
control. 

4.3.7.4.2.3 APN based Mobility Management congestion control 

The MME may perform the APN based congestion control for UEs with a particular subscribed APN by rejecting 
Attach procedures with a Mobility Management back-off timer. 

The MME may store a Mobility Management back-off time when congestion control is active for UEs with a particular 
subscribed APN. The MME may immediately reject any subsequent request from the UE with this subscribed APN 
before the stored back-off time is expired. 

NOTE 1 : The above functionality is to diminish the performance advantage for UEs that do not support the NAS 
level back-off timer (e.g. pre-Rel-10 UEs) compared to UEs that do support it. 

After rejecting Attach Requests, the MME should keep the Subscriber Data for some time. This allows for rejection of 
subsequent requests without HSS signalling when the congestion situation resulting from UEs with a particular 
subscribed APN persists. 
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NOTE 2: Prior to the reject of attach messages of a UE by the MME, Subscriber Data for a UE may be present at 
the MME because it was not deleted after the UE's detach. In this case when APN based congestion 
control is active for a particular APN in the MME, the first reject of an attach message by the MME for 
this UE, may be done without HSS signaling as well. 

While the Mobility Management back-off timer is running, the UE shall not initiate any Mobility Management 
procedures. However, the UE is allowed to initiate the Mobility Management procedures for Service Users, emergency 
services and mobile terminated services even when the Mobility Management back-off timer is running. 

To avoid that large amounts of UEs initiate deferred requests (almost) simultaneously, the MME should select the 
MobiUty Management back-off timer value so that deferred requests are not synchronized. 

NOTE 3: When receiving the Mobility Management back-off timer the UE behaviour is not APN specific. 

4.3.7.4.2.4 General NAS level Mobility Management congestion control 

Under general overload conditions the MME may reject Mobility Management signalling requests from UEs. When a 
NAS request is rejected, a Mobility Management back-off timer may be sent by the MME. While the Mobility 
Management back-off timer is running, the UE shall not initiate any NAS request except for Service Users, emergency 
services and mobile terminated services. The Mobility Management back-off timer shall not impact Cell/RAT and 
PLMN change. Cell/RAT and TA change do not stop the Mobility Management back-off timer. 

The Mobility Management back-off timer shall not be a trigger for PLMN reselection. The back-off timer is stopped as 
defined in TS 24.301 [46] when a new PLMN that is not an equivalent PLMN is accessed. 

To avoid that large amounts of UEs initiate deferred requests (almost) simultaneously, the MME shall decorrelate the 
MobiUty Management back-off timer. 

The MME should not reject Tracking Area Update procedures that are performed in connected mode, i.e. when 
performed as part of a handover. 

For idle mode inter CN node mobility, the MME may reject Tracking Area Update procedures and include a . Mobility 
Management back off timer value in the Tracking Area Reject message. 

NOTE The UE does not perform a TAU until expiry of the MM backoff timer. When the congested target CN 
node includes a very large Mobility Management back-off timer value in the Routing Area Reject 
message to the UE, the implicit detach timer, or other internal guard timer, in the source CN node could 
expire before receiving the Tracking Area Update from the UE. The source CN node might incorrectly 
interpret the expiry of this implicit detach timer as lost communication with the UE and implicitly detach 
the UE. This could result in unnecessary signaling after Mobility Management back off timer expiry. 
Therefore, a smaller back off timer may be appropriate in this case. 

4.3.7.5 PDN GW control of overload 

The PDN GW may provide mechanisms for avoiding and handling overload situations. These include the rejection of 
PDN connection requests from UEs. 

The PDN GW may detect APN congestion and start and stop performing overload control based on criteria such as: 

Maximum number of active bearers per APN; and/or 

Maximum rate of bearer activations per APN. 

When performing overload control the PDN GW rejects PDN connection requests. When receiving the rejection from 
the PDN GW, the MME rejects the UE's PDN connection request as specified in clause 4.3.7.4.2. In addition the PDN 
GW may indicate a "PDN-GW back-off time" for a specific APN to the MME. The MME should reject PDN 
connection requests, for the specific APN related to that PDN GW during the "PDN GW back-off time", by the means 
specified in clause 4.3.7.4.2. If a PDN GW indicates APN congestion by the "PDN GW back-off time" the MME may 
select another PDN GW of that APN instead of rejecting PDN connection requests. 
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4.3.8 Selection functions 

4.3.8.1 PDN GW selection function (3GPP accesses) 

The PDN GW selection function allocates a PDN GW that shall provide the PDN connectivity for the 3GPP access. The 
function uses subscriber information provided by the HSS and possibly additional criteria such as SIPTO/LIPA support 
per APN configured in the SGSN/MME. The criteria for PDN GW selection may include load balancing between PDN 
GWs. When the PDN GW IP addresses returned from the DNS server include Weight Factors, the MME should use it if 
load balancing is required. The Weight Factor is typically set according to the capacity of a PDN GW node relative to 
other PDN GW nodes serving the same APN. For further details on the DNS procedure see TS 29.303 [61]. 

The PDN subscription contexts provided by the HSS contain: 

the identity of a PDN GW and an APN (PDN subscription contexts with subscribed PDN GW address are not 
used when there is interoperation with pre Rel-8 2G/3G SGSN), or 

an APN and an indication for this APN whether the allocation of a PDN GW from the visited PLMN is allowed 
or whether a PDN GW from the home PLMN shall be allocated. Optionally an identity of a PDN GW may be 
contained for handover with non-3GPP accesses. 

optionally for an APN, an indication of whether SIPTO is allowed or prohibited for this APN. 

optionally for an APN, an indication of whether LIPA is conditional, prohibited, or only LIPA is supported for 
this APN. 

In the case of static address allocation, a static PDN GW is selected by either having the APN configured to map to a 
given PDN GW, or the PDN GW identity provided by the HSS indicates the static PDN GW. 

The HSS also indicates which of the PDN subscription contexts is the Default one for the UE. 

To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the 
requested APN for the PDN GW selection function. 

If one of the PDN subscription contexts provided by the HSS contains a wild card APN (see TS 23.003 [9]), a PDN 
connection with dynamic address allocation may be established towards any APN requested by the UE. An indication 
that SIPTO is allowed or prohibited for the wild card APN allows or prohibits SIPTO for any APN that is not present in 
the subscription data. 

If the HSS provides the identity of a statically allocated PDN GW, or the HSS provides the identity of a dynamically 
allocated PDN GW and the Request Type indicates "Handover", no further PDN GW selection functionality is 
performed. If the HSS provides the identity of a dynamically allocated PDN GW, the HSS also provides information 
that identifies the PLMN in which the PDN GW is located. 

NOTE 1 : The MME uses this information to determine an appropriate APN-OI and S8 protocol type (PMIP or 
GTP) when the MME and PDN GW are located in different PLMNs. 

If the HSS provides the identity of a dynamically allocated PDN GW and the Request Type indicates "initial Request", 
either the provided PDN GW is used or a new PDN GW is selected. When a PDN connection with SIPTO is requested, 
the PDN GW selection function shall ensure the selection of a PDN GW that is appropriate for the UE's location. The 
PDN GW identity refers to a specific PDN GW. If the PDN GW identity includes the IP address of the PDN GW, that 
IP address shall be used as the PDN GW IP address; otherwise the PDN GW identity includes an FQDN which is used 
to derive the PDN GW IP address by using Domain Name Service function, taking into account the protocol type on 
S5/S8 (PMIP or GTP). 

NOTE 2: Provision of a PDN GW identity of a PDN GW as part of the subscriber information allows also for a 
PDN GW allocation by HSS. 

If the HSS provides a PDN subscription context that allows for allocation of a PDN GW from the visited PLMN for this 
APN, the PDN GW selection function derives a PDN GW identity from the visited PLMN. If a visited PDN GW 
identity cannot be derived, or if the subscription does not allow for allocation of a PDN GW from the visited PLMN, 
then the APN is used to derive a PDN GW identity from the HPLMN. The PDN GW identity is derived from the APN, 
subscription data and additional information by using the Domain Name Service function. If the PDN GW identity is a 
logical name instead of an IP address, the PDN GW address is derived from the PDN GW identity, protocol type on 
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S5/S8 (PMIP or GTP) by using the Domain Name Service function. The S8 protocol type (PMIP or GTP) is configured 
per HPLMN in MME/SGSN. 

In order to select the appropriate PDN GW for SIPTO service, the PDN GW selection function uses the TAX (Tracking 
Area Identity), the serving eNodeB identifier, or TAI together with serving eNodeB identifier depending on the 
operator's deployment during the DNS interrogation as specified in TS 29.303 [61] to find the PDN GW identity. In 
roaming scenario PDN GW selection for SIPTO is only possible when a PDN GW in the visited PLMN is selected. 
Therefore in a roaming scenario with home routed traffic, PDN GW selection for SIPTO is not performed. 

In order to select the appropriate L-GW for LIPA service, if permitted by the CSG subscription data and if the UE is 
roaming, the VPLMN LIPA is allowed, the PDN GW selection function uses the L-GW address proposed by HeNB in 
the Sl-AP message, instead of DNS interrogation. If no L-GW address is proposed by the HeNB and the UE requested 
an APN with LIPA permissions set to "LIPA-only", the request shall be rejected. If no L-GW address is proposed by 
the HeNB and the UE requested an APN with LIPA permissions set to "LIPA-conditional", the MME uses DNS 
interrogation for PGW selection to establish a non-LIPA PDN connection. The PDN subscription context for an APN 
with LIPA permissions set to "LIPA-only" shall not contain a statically configured PDN address or a statically allocated 
PDN GW. A static PDN address or a static PDN GW address, if configured by HSS for an APN with LIPA permissions 
set to "LIPA-conditional", is ignored by MME when the APN is established as a LIPA PDN connection. When 
establishing a PDN connection for a LIPA APN, the VPLMN Address Allowed flag is not considered. 

The PDN GW domain name shall be constructed and resolved by the method described in TS 29.303 [61], which takes 
into account any value received in the APN-OI Replacement field for home routed traffic. Otherwise, or when the 
resolution of the above PDN GW domain name fails, the PDN GW domain name shall be constructed by the serving 
node using the method specified in Annex A of TS 23.060 [7] and clause 9 of TS 23.003 [9]. If the Domain Name 
Service function provides a list of PDN GW addresses, one PDN GW address is selected from this list. If the selected 
PDN GW cannot be used, e.g. due to an error, then another PDN GW is selected from the list. The specific interaction 
between the MME/SGSN and the Domain Name Service function may include functionality to allow for the retrieval or 
provision of additional information regarding the PDN GW capabilities (e.g. whether the PDN GW supports 
PMIP-based or GTP-based S5/S8, or both). 

NOTE 3: The APN as constructed by the MME/SGSN for PDN GW resolution takes into account the APN-OI 
Replacement field. This differs from the APN that is provided in charging data to another SGSN and 
MME over the S3, SIO and S 16 interfaces as well as to Serving GW and PDN GW over the SU, S4and 
S5/S8 interfaces, in that the APN-OI Replacement field is not applied. See clause 5.7.2 of the present 
document for more details. 

If the UE provides an APN for a PDN, this APN is then used to derive the PDN GW identity as specified for the case of 
HSS provided APN if one of the subscription contexts allows for this APN. 

If there is an existing PDN connection to the same APN used to derive the PDN GW address, the same PDN GW shall 
be selected. 

As part of PDN GW selection, an IP address of the assigned PDN GW may be provided to the UE for use with host 
based mobility as defined in TS 23.402 [2], if the PDN GW supports host-based mobility for inter-access mobility 
towards accesses where host-based mobility can be used. If a UE explicitly requests the address of the PDN GW and the 
PDN GW supports host based mobility then the PDN GW address shall be returned to the UE. 

4.3.8.2 Serving GW selection function 

The Serving GW selection function selects an available Serving GW to serve a UE. The selection bases on network 
topology, i.e. the selected Serving GW serves the UE's location and for overlapping Serving GW service areas, the 
selection may prefer Serving GWs with service areas that reduce the probability of changing the Serving GW. When 
SIPTO is allowed then it is also considered as a criterion for Serving GW selection, e.g. when the first PDN connection 
is requested. Other criteria for Serving GW selection should include load balancing between Serving GWs. When the 
Serving GW IP addresses returned from the DNS server include Weight Factors, the MME should use it if load 
balancing is required. The Weight Factor is typically set according to the capacity of a Serving GW node relative to 
other Serving GW nodes serving the same Tracking area. For further details on DNS procedure see TS 29.303 [61]. 

If a subscriber of a GTP only network roams into a PMIP network, the PDN GWs selected for local breakout support 
the PMIP protocol, while PDN GWs for home routed traffic use GTP. This means the Serving GW selected for such 
subscribers may need to support both GTP and PMIP, so that it is possible to set up both local breakout and home 
routed sessions for these subscribers. For a Serving GW supporting both GTP and PMIP, the MME/SGSN should 
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indicate the Serving GW which protocol should be used over S5/S8 interface. The MME/SGSN is configured with the 
S8 variant(s) on a per HPLMN granularity. 

If a subscriber of a GTP only network roams into a PMIP network, the PDN GWs selected for local breakout may 
support GTP or the subscriber may not be allowed to use PDN GWs of the visited network. In both cases a GTP only 
based Serving GW may be selected. These cases are considered as roaming between GTP based operators. 

If combined Serving and PDN GWs are configured in the network the Serving GW Selection Function preferably 
derives a Serving GW that is also a PDN GW for the UE. 

The Domain Name Service function may be used to resolve a DNS string into a list of possible Serving GW addresses 
which serve the UE's location. The specific interaction between the MME/SGSN and the Domain Name Service 
function may include functionality to allow for the retrieval or provision of additional information regarding the Serving 
GW capabilities (e.g. whether the Serving GW supports PMIP -based or GTP -based S5/S8, or both). The details of the 
selection are implementation specific. 

For handover from non-3GPP accesses in roaming scenario, the Serving GW selection function for local anchoring is 
described in TS 23.402 [2]. 

The Serving GW selection function in the MME is used to ensure that all Tracking Areas in the Tracking Area List 
belong to the same Serving GW service area. 

4.3.8.3 MME selection function 

The MME selection function selects an available MME for serving a UE. The selection is based on network topology, 
i.e. the selected MME serves the UE's location and for overlapping MME service areas, the selection may prefer MMEs 
with service areas that reduce the probability of changing the MME. When a MME/SGSN selects a target MME, the 
selection function performs a simple load balancing between the possible target MMEs. 

When an eNodeB selects an MME, the eNodeB may use a selection function which distinguishes if the GUMMEI is 
mapped from P-TMSI/RAI or is a native GUMMEI. The indication of mapped or native GUMMEI shall be signalled by 
the UE to the eNodeB as an explicit indication. The eNodeB may differentiate between a GUMMEI mapped from 
P-TMSI/RAI and a native GUMMEI based on the indication signalled by the UE. Alternatively, the differentiation 
between a GUMMEI mapped from P-TMSI/RAI and a native GUMMEI may be performed based on the value of most 
significant bit of the MME Group ID, for PLMNs that deploy such mechanism. In this case, if the MSB is set to "0" 
then the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one. Alternatively 
the eNodeB makes the selection of MME only based on the GUMMEI without distinguishing on mapped or native. 

When an eNodeB selects an MME, the selection shall achieve load balancing as specified in clause 4.3.7.2. 

4.3.8.4 SGSN selection function 

The SGSN selection function selects an available SGSN to serve a UE. The selection is based on network topology, i.e. 
the selected SGSN serves the UE's location and for overlapping SGSN service areas, the selection may prefer SGSNs 
with service areas that reduce the probability of changing the SGSN. When a MME/SGSN selects a target SGSN, the 
selection function performs a simple load balancing between the possible target SGSNs. 

4.3.8.5 Selection of PCRF 

The PDN GW and AF may be served by one or more PCRF nodes in the HPLMN and, in roaming with local breakout 
scenarios, one or more PCRF nodes in the VPLMN. 

The selection of PCRF and linking of the different UE's PCC sessions over the multiple PCRF interfaces (e.g. Rx 
session, Gx session, S9 session etc.) for a UE IP CAN session is described in TS 23.203 [6]. 

4.3.9 IP network related functions 
4.3.9.1 Domain Name Service function 

The Domain Name Service function resolves logical PDN GW names to PDN GW addresses. This function is standard 
Internet functionality according to RFC 1034 [17], which allows resolution of any name to an IP address (or addresses) 
for PDN GWs and other nodes within the EPS. 
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4.3.9.2 DHCP function 

The Dynamic Host Configuration Function allows to deliver IP configuration information for UEs. This function is 
standard Internet functionahty according to RFC 2131 [19], RFC 3736 [20], RFC 3633 [21] and RFC 4039 [25]. 

4.3.9.3 Explicit Congestion Notification 

The E-UTRAN/UTRAN and the UE support the RFC 3168 [55] Explicit Congestion Notification (ECN), as described 
in TS 36.300 [5], TS 25.401 [16] and TS 26.1 14 [56]. 

4.3.1 Functionality for Connection of eNodeBs to Multiple MMEs 

An eNodeB may connect to several MMEs. This implies that an eNodeB must be able to determine which of the 
MMEs, covering the area where an UE is located, should receive the signalling sent from a UE. To avoid unnecessary 
signalling in the core network, a UE that has attached to one MME should generally continue to be served by this MME 
as long as the UE is in the radio coverage of the pool area to which the MME is associated. The concept of pool area is 
a RAN based definition that comprises one or more TA(s) that, from a RAN perspective, are served by a certain group 
of MMEs. This does not exclude that one or more of the MMEs in this group serve TAs outside the pool area. This 
group of MMEs is also referred to as an MME pool. 

To enable the eNodeB to determine which MME to select when forwarding messages from an UE, this functionality 
defines a routing mechanism (and other related mechanism). A routing mechanism (and other related mechanism) is 
defined for the MMEs. The routing mechanism is required to find the correct old MME (from the multiple MMEs that 
are associated with a pool area). When a UE roams out of the pool area and into the area of one or more MMEs that do 
not know about the internal structure of the pool area where the UE roamed from, the new MME will send the 
Identification Request message or the Context Request message to the old MME using the GUTI. The routing 
mechanism in both the MMEs and the eNodeB utilises the fact that every MME that serves a pool area must have its 
own unique value range of the GUTI parameter within the pool area. 

4.3.1 1 E-UTRAN Sharing Function 

E-UTRAN Sharing is an agreement between operators and shall be transparent to the user. This implies that an 
E-UTRAN UE needs to be able to discriminate between core network operators available in a shared radio access 
network and that these operators can be handled in the same way as operators in non-shared networks. E-UTRAN 
terminals support E-UTRAN Sharing. 

An E-UTRAN Sharing architecture allows different core network operators to connect to a shared radio access network. 
The operators do not only share the radio network elements, but may also share the radio resources themselves. In 
addition to this shared radio access network the operators may or may not have additional dedicated radio access 
networks, like for example, 3G or 2G radio access networks. For E-UTRAN both Multi-Operator Core Network 
(MOCN) configuration and Gateway Core Network (GWCN) configuration as defined in TS 23.251 [24] are supported 
over the S 1 reference point. E-UTRAN terminals shall support shared networks and hence, only functions for 
"Supporting UEs" in TS 23.251 [24] applies for E-UTRAN Sharing. 

E-UTRAN Radio Access Network Sharing functions is further described in TS 36.300 [5]. 

In networks that support network sharing as defined in TS 23.251 [24], for a UE in state ECM-CONNECTED, the 
Handover Restriction List provided by the core-network to the radio access network is also used to inform the radio 
access network about the Selected PLMN and equivalent PLMNs as defined in TS 36.413 [36]. 



4.3.12 IMS Emergency Session Support 



4.3.12.1 Introduction 

Clause 4.3.12 IMS Emergency Session provides an overview about functionality for emergency bearer services in a 
single clause. The specific functionality is described in the affected procedures and functions of this specification. For 
discrepancies between this overview clause and the detailed procedure and function descriptions the latter take 
precedence. 
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Emergency bearer services are provided to support IMS emergency sessions. Emergency bearer services are 
functionalities provided by the serving network when the network is configured to support emergency services. 
Emergency bearer services are provided to normal attached UEs and depending on local regulation, to UEs that are in 
limited service state. Receiving emergency services in limited service state does not require a subscription. Depending 
on local regulation and an operator's policy, the MME may allow or reject an emergency attach request for UEs in 
limited service state. Four different behaviours of emergency bearer support have been identified as follows: 

a. Valid UEs only. No limited service state UEs are supported in the network. Only normal UEs that have a valid 
subscription, are authenticated and authorized for PS service in the attached location are allowed. It is not 
expected that a normal UE would perform an emergency attach. Normal UEs should be attached to the network 
and then perform a PDN Connection Request when an IMS emergency session is detected by the UE. 

b. Only UEs that are authenticated are allowed. These UEs must have a vahd IMS I. These UEs are 
authenticated and may be in limited service state due to being in a location that they are restricted from service. 
A UE that can not be authenticated will be rejected. 

c. IMSI required, authentication optional. These UEs must have an IMSI. If authentication fails, the UE is 
granted access and the unauthenticated IMSI retained in the network for recording purposes. The IMEI is used in 
the network as the UE identifier. IMEI only UEs will be rejected (e.g., UlCCless UEs). 

d. All UEs are allowed. Along with authenticated UEs, this includes UEs with an IMSI that can not be 
authenticated and UEs with only an IMEI. If an unauthenticated IMSI is provided by the UE, the unauthenticated 
IMSI is retained in the network for recording purposes. The IMEI is used in the network to identify the UE. 

To provide emergency bearer services, the MME is configured with MME Emergency Configuration Data that are 
applied to all emergency bearer services that are established by an MME on UE request. The MME Emergency 
Configuration Data contain the Emergency APN which is used to derive a PDN GW, or the MME Emergency 
Configuration Data may also contain the statically configured PDN GW for the Emergency APN. 

UEs that are in limited service state, as specified in TS 23.122 [10], initiate the Attach procedure with indicating that the 
attach is to receive emergency services. Also UEs that had attached for normal services and do not have emergency 
bearers established and are camped on a cell in limited service state (e.g. because of restricted Tracking Area or not 
allowed CSG) shall initiate this Attach procedure, indicating that the attach is to receive emergency services. The 
network supporting emergency services for UEs in limited service state provides emergency bearer services to these 
UE, regardless whether the UE can be authenticated, has roaming or mobility restrictions or a valid subscription, 
depending on local regulation. The UEs in limited service state determine that the cell supports emergency services over 
E-UTRAN from a broadcast indicator in AS. 

For a UE that is Emergency Attached, if it is unauthenticated the EPS security context is not set up on UE. 

UEs that camp normally on a cell, i.e. without any conditions that result in limited service state, initiate the normal 
initial attach procedure if not already attached. Normal attached UEs initiate the UE Requested PDN Connectivity 
procedure to receive emergency bearer services. The UEs that camp normally on a cell are informed that the PLMN 
supports emergency services over E-UTRAN from the Emergency Service Support indicator in the Attach and TAU 
procedures. 

For a UE that is Emergency Attached, normal PLMN selection principles apply after the end of the IMS emergency 
session. 

For emergency bearer services any EPC functions, procedures and capabilities are provided according to clause 4 
except when specified differently in the following sections. 

For emergency bearer services there is no support of inter PLMN mobility in this version of the specification. 

For emergency bearer services there is no support of handover from non-3GPP access to E-UTRAN access in this 
version of the specification. 

The UE shall set the RRC establishment cause to emergency as defined in TS 36.331 [37] when it requests an RRC 
connection in relation to an emergency session. Specific situations that require setting the RRC establishment cause to 
emergency are described in TS 24.301 [46]. 

When a PLMN supports IMS emergency services, all MMEs in that PLMN shall have the same capability to support 
emergency bearer services. 
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NOTE: Idle mode Signalling Reduction (ISR) is not supported by the network for UEs that only have bearers 
related to emergency bearer service. 

4.3.1 2.2 Architecture Reference Model for Emergency Services 

According to clause 4.2, the non-roaming architectures (Figure 4.2.1-1 and Figure 4.2.1-2) and roaming architecture 
with the visited operator's application function (Figure 4.2.2-3) apply for emergency services. The other roaming 
architectures with services provided by the home network do not apply for emergency services. 

4.3.12.3 Mobility and Access Restrictions for Emergency Services 

When Emergency Services are supported and local regulation requires Emergency Calls to be provided regardless of 
mobility or access restrictions, the Mobility Restrictions in clause 4.3.5.7, should not be applied to UEs receiving 
emergency services. When the E-RABs for emergency bearers are established, the ARP values for emergency bearer 
services indicate the usage for emergency services to the E-UTRAN. The source E-UTRAN and source MME ignore 
any UE related restrictions during handover evaluation when there are active emergency bearers. E-UTRAN shall not 
initiate handover to GERAN PS domain. 

During Tracking Area Update procedures, including a TAU as part of a handover, the target MME ignores any mobility 
or access restrictions for UE with emergency bearer services where required by local regulation. Any non emergency 
bearer services are deactivated, according to clause 5.10.3, by the target MME when not allowed by the subscription for 
the target location. Such UEs behave as emergency attached. To allow the emergency attached UE to get access to 
normal services after the emergency call has ended and when it has moved to a new area that is not stored by the UE as 
a forbidden area, the UE may explicitly detach and reattach to normal services without waiting for the emergency PDN 
connection deactivation by the PDN GW. 

This functionality applies to all mobility procedures. 

4.3.1 2.3a Reachability Management for UE in ECM-IDLE state 

An emergency attached UE when its periodic TAU update timer expires shall not initiate a periodic TAU procedure but 
enter EMM-DEREGISTERED state. For emergency attached UEs the MME runs a mobile reachable timer with a 
similar value to the UE's periodic TAU timer. Any time after expiry of this timer the MME may change the EMM state 
of an emergency attached UE to EMM-DEREGISTERED. The MME assigns the periodic TAU timer value to 
emergency attached UE. This timer keeps the UE emergency attached after change to EMM-IDLE state to allow for a 
subsequent emergency service without a need to emergency attach again. 

4.3.12.4 PDN GW selection function (3GPP accesses) for Emergency Services 

When a PDN GW is selected for IMS emergency call support, the PDN GW selection function described in 
clause 4.3.8.1 for normal bearer services is applied to the Emergency APN or the MME selects the PDN GW directly 
from the MME Emergency Configuration Data. If the PDN GW selection function described in clause 4.3.8.1 is used it 
shall always derive a PDN GW in the visited PLMN, which guarantees that also the IP address is allocated by the 
visited PLMN. In networks that support handover between E-UTRAN and HRPD accesses, the MME selects a PDN 
GW that is statically configured in the MME Emergency Configuration Data. The PDN GW selection does not depend 
on subscriber information in the HSS since emergency call support is a local, not subscribed service. The MME 
Emergency Configuration Data contains the Emergency APN which is used to derive a PDN GW, or the MME 
Emergency Configuration Data may also contain the statically configured PDN GW for the Emergency APN. 

This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases 
when establishing emergency bearer services. 

NOTE: It is assumed that the same PDN GW is configured in 3GPP and HRPD accesses. 

4.3.1 2.5 QoS for Emergency Services 

Where local regulation require supporting calls from an unauthorised caller, the MME may not have subscription data. 
Additionally, the local network may want to provide IMS emergency call support differently than what is allowed by a 
UE subscription. Therefore, the initial QoS values used for establishing emergency bearer services are configured in the 
MME in the MME Emergency Configuration Data. If PCC is not deployed the PDN GW sets the ARP value that is 
reserved for emergency services, which the PDN GW bases on the usage of the Emergency APN. 
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This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases 
when establishing emergency bearer services. 

4.3.1 2.6 PCC for Emergency Services 

When dynamic PCC is used for UEs establishing emergency service, the procedures are as described in TS 23.203 [6]. 
When establishing emergency bearer services with a PDN GW and dynamic policy is used, according to clause 4.7.5, 
the PCRF provides the PDN GW with the QoS parameters, including an ARP value reserved for the emergency bearers 
to prioritize the bearers when performing admission control. According to clause 4.7.5, local configuration of static 
policy functions is also allowed and not subject to standardization. 

The PCRF ensures that the emergency PDN connection is used only for IMS emergency sessions. The PCRF rejects an 
IMS session established via the emergency PDN connection if the AF (i.e. P-CSCF) does not provide an emergency 
indication to the PCRF. 

This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases 
when establishing emergency bearer services. 

4.3.12.7 Load re-balancing between MMEs for Emergency Services 

As per load re-balancing procedures in clause 4.3.7.3, the MME is allowed to off-load ECM-CONNECTED mode UEs 
by initiating SI Release procedures. When a UE is in ECM-CONNECTED mode with an active emergency bearer 
service, the MME should not release the UE for load re-balancing. The MME should wait until the UE initiates a TAU 
or becomes inactive. The MME may release the UE under critical conditions such as the need to perform an MME node 
restart. 

4.3.1 2.8 IP Address Allocation 

Emergency bearer service is provided by the serving PLMN. The UE and PLMN must have compatible IP address 
versions in order for the UE to obtain a local emergency PDN connection. IP address allocation in the serving PLMN is 
provided per clause 5.3.1 with the exception that the PDN GW associated with the emergency APN shall support PDN 
type IPv4 and PDN type IPv6. 

4.3.1 2.9 Handling of PDN Connections for Emergency Bearer Services 

The default and dedicated EPS bearers of a PDN Connection associated with the emergency APN shall be dedicated for 
IMS emergency sessions and shall not allow any other type of traffic. The emergency bearer contexts shall not be 
changed to non-emergency bearer contexts and vice versa. The PDN GW shall block any traffic that is not from or to 
addresses of network entities (e.g. P-CSCF) providing IMS emergency service. If PCC is not deployed, the list of 
allowed addresses may be configured in the PDN GW by the operator. When dynamic PCC is deployed, the procedures 
are as described in TS 23.203 [6]. If there is already an emergency PDN GW connection, the UE shall not request 
another emergency PDN Connection. The MME shall reject any additional emergency PDN Connection requests. The 
UE shall not request any bearer resource modification for the emergency PDN connection. The PDN GW shall reject 
any UE requested bearer resource modification that is for the emergency PDN Connection. The ARP reserved for 
emergency bearer service shall only be assigned to EPS bearers associated with an emergency PDN Connection. When 
PCC is not used the PDN GW provides static policy. 

4.3.1 2.1 ISR function for Emergency Bearer Services 

When UE has only emergency bearer service, ISR does not apply. 

4.3.13 Closed Subscriber Group functions 

Closed Subscriber Group identifies a group of subscribers who are permitted to access one or more CSG cells of the 
PLMN as a member of the CSG for a HeNB. The following CSG related functions are defined: 

CSG subscription handling function stores and updates the user's CSG subscription data at the UE and the 
network. 

For closed mode, CSG access control function ensures a UE has valid subscription at a CSG where it performs 
an access. 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 39 ETSI TS 1 23 401 V1 0.3.0 (201 1 -03) 

Admission and rate control function is used to provide different admission and rate control for CSG and non- 
CSG members for a hybrid CSG cell. 

CSG charging function enables per CSG charging for a subscriber consuming network services via a CSG cell or 
a hybrid cell. 

Paging optimization function is optionally used to filter paging messages based on TAI List, user's CSG 
subscription data and CSG access mode in order to avoid paging at CSG cells where the UE is not allowed to 

access. 

4.3.14 Location Service functions 

LCS procedures are described in the LCS stage 2 specification, see TS 23.271 [57]. 

4.3.15 Selected IP Traffic Offload (SIPTO) function 

The SIPTO function enables an operator to offload certain types of traffic at a network node close to that UE's point of 
attachment to the access network. 

SIPTO can be achieved by selecting a set of GWs (S-GW and P-GW) that is geographically/topologically close to a 
UE's point of attachment. SIPTO applies to both the non-roaming case and, provided appropriate roaming agreements 
are in place between the operators, to the roaming case. 

Offload of traffic for a UE is available for UTRAN and E-UTRAN accesses only. When the UE enters to UTRAN/E- 
UTRAN from another type of access network (e.g., from GERAN), it is the responsibility of the new SGSN/MME to 
decide whether to perform deactivation with reactivation request for a given PDN connection for SIPTO purposes. 

Realization for SIPTO relies on the same architecture models and principles as for local breakout described in 

clause 4.2. 

In order to select a set of appropriate GW (S-GW and P-GW) based on geographical/topological proximity to UE, the 
GW selection function specified in TS 29.303 [61] uses the UE's current location information. 

In order for the operator to allow/prohibit SIPTO on per user and per APN basis, subscription data in the HSS is 
configured to indicate to the MME if offload is allowed or prohibited. If the SIPTO allowed/prohibited information 
from the HSS conflicts with MME's configuration for that UE, then SIPTO is not used. 

If HSS indicates VPLMN address not allowed, then VPLMN (i.e. MME) shall not provide SIPTO. 

In the absence of any SIPTO allowed/prohibited indication from the HSS the VPLMN (i.e MME) shall not provide 
SIPTO. 

The MME may be configured on a per APN basis as to whether or not to use SIPTO (e.g. to handle the case where the 
HSS is not configured with SIPTO information for the UE). 

As a result of UE mobility (e.g. detected by the MME at TAU or SGSN at RAU or movement from GERAN), the target 
MME may wish to redirect a PDN connection towards a different GW that is more appropriate for the UE's current 
location, e.g. MME may know whether the UE's new location is served by the same GW as the old one. When the 
MME decides upon the need for GW relocation, the MME deactivates the impacted PDN connections indicating 
"reactivation requested" as specified in clause 5. 10.3. If all of the PDN connections for the UE need to be relocated, the 
MME may initiate the "explicit detach with reattach required" procedure as specified in clause 5.3.8.3. 

NOTE: If either of the above procedures for GW relocation are initiated while the UE has active applications, it 
may cause disruption of services that are affected if the IP address changes. 

4.3.1 6 Local IP Access (LIPA) function 

The LIPA function enables an IP capable UE connected via a HeNB to access other IP capable entities in the same 
residential/enterprise IP network without the user plane traversing the mobile operator's network except HeNB 
subsystem. 

The Local IP Access is achieved using a Local GW (L-GW) colocated with the HeNB. 
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LIPA is established by the UE requesting a new PDN connection to an APN for which LIPA is permitted, and the 
network selecting the Local GW associated with the HeNB and enabling a direct user plane path between the Local GW 
and the HeNB. The HeNB supporting the LIPA function includes the Local GW address to the MME in every INITIAL 
UE MESSAGE and every UPLINK NAS TRANSPORT control message as specified in TS 36.413 [36]. 

NOTE 1: The protocol option (i.e. GTP or PMIP) supported on the S5 interface between Local GW and S-GW is 
configured on the MME. 

For this release of the specification no interface between the L-GW and the PCRF is specified and there is no support 
for Dedicated bearers on the PDN connection used for Local IP Access. The Local GW (L-GW) shall reject any UE 
requested bearer resource modification. 

The direct user plane path between the HeNB and the collocated L-GW is enabled with a Correlation ID parameter that 
is associated with the default EPS bearer on a PDN connection used for Local IP Access. Upon establishment of the 
default EPS bearer the MME sets the Correlation ID equal to the PDN GW TEID (GTP -based S5) or the PDN GW 
GRE key (PMIP-based S5). The Correlation ID is then signalled by the MME to the HeNB as part of E-RAB 
establishment and is stored in the E-RAB context in the HeNB. The Correlation ID is used in the HeNB for matching 
the radio bearers with the direct user plane path connections from the collocated L-GW. 

If the UE is roaming and if the HSS indicates LIPA roaming allowed for this UE in this VPLMN, then the VPLMN (i.e. 
MME) may provide LIPA for this UE. Furthermore, in the absence of any LIPA information for the requested APN 
from the HSS, the VPLMN (i.e MME) shall not provide LIPA. The VPLMN address allowed flag is not considered 
when establishing a LIPA PDN connection. 

LIPA is supported for APNs that are valid only when the UE is connected to a specific CSG. LIPA is also supported for 
"conditional" APNs that can be authorized to LIPA service when the UE is using specific CSG. APNs marked as "LIPA 
prohibited" or without a LIPA permission indication cannot be used for LIPA. 

As mobility of the LIPA PDN connection is not supported in this release of the specification, the LIPA PDN connection 
shall be released when the UE moves away from H(e)NB. Before starting the handover procedure towards the target 
RAN, the H(e)NB shall request using an intra-node signalling the collocated L-GW to release the LIPA PDN 
connection. The H(e)NB determines that the UE has a LIPA PDN connection from the presence of the Correlation ID in 
the UE (E-)RAB context. The L-GW shall then initiate and complete the release of the LIPA PDN connection using the 
PDN GW initiated bearer deactivation procedure as per clause 5.4.4.1 or GGSN initiated PDP context deactivation 
procedure as specified in TS 23.060 [7]. The H(e)NB shall not proceed with the handover preparation procedure 
towards the target RAN until the UE's (E-)RAB context is clear for the Correlation ID. 

At the handover, the source MME verifies that the LIPA PDN connection has been released: 

and the handover is the SI -based handover or the Inter-RAT handover, the source MME shall reject the 
handover. 

and the handover is X2-based handover, the MME shall send a Path Switch Request Failure message (see more 
detail in TS 36.413 [36]) to the target HeNB. The MME performs explicit detach of the UE as described in the 
MME initiated detach procedure of clause 5.3.8.3. 

NOTE 2: The direct signalling (implementation dependent) from the H(e)NB to the L-GW is only possible since 
mobility of the LIPA PDN connection is not supported in this release. 

During idle state mobility events, the MME/SGSN shall deactivate the LIPA PDN connection when it detects that the 
UE has moved away from the HeNB. 

4.3.1 7 Support for Machine Type Communications (MTC) 
4.3.17.1 General 

This clause provides an overview about functionality for Machine Type Communications according to service 
requirements described in TS 22.368 [66]. The specific functionality is described in the affected procedures and features 
of this and other specifications. For discrepancies between this overview clause and the detailed procedure and function 
descriptions, the latter take precedence. 
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MTC functionality is provided by the visited and home networks when the networks are configured to support machine 
type communication. It appHes to both the non-roaming case and the roaming case and some functionahty may be 
dependent upon the existence of appropriate roaming agreements between the operators. 

Some of the MTC functions are controlled by subscriber data. Other MTC functions are based on indicators sent by the 
UE to the network. MTC functionality is performed by UEs that are configured to support different options as described 
in clause 4.3.17.4. 

4.3.17.2 Overview of protection from Potential MTC Related Overload 

The number of MTC devices may be several orders of magnitude greater than "traditional" devices. Many (but not all) 
MTC devices will be relatively stationary and/or generate low volumes of traffic. However, these UEs have the 
capability to generate normal quantities of signalling. 

The total signalling from large numbers of MTC devices is a concern in at least two situations: 

when an application requests many these MTC devices to do "something" at the same time; and/or 

when many MTC devices are roamers and their serving network fails, then they can all move onto the local 
competing networks, and potentially overload the not (yet) failed network(s). 

To counter these potential problems, the following standardised indications and mechanisms are provided. These permit 
node specific features to be developed to protect the networks. 

a) Where applicable, UEs can be configured for enhancements as described in subsequent bullets Post- 
manufacturing configuration can be performed remotely as described in clause 4.3.17.4. 

b) For mobile originated services, UEs configured for low access priority provide the E-UTRAN with information 
indicating that the RRC connection establishment is for signalling or user data from a UE configured for low 
access priority (see clause 4.3.17.4). 

c) RRC signalling has the capability of providing 'extended wait timers' when rejecting messages. 

d) The MME can initiate rejection of RRC connection establishments in the E-UTRAN for certain subcategories of 
UEs as described in clause 4.3.7.4.1. 

e) Overload messages from the MME to E-UTRAN are extended to aid the RAN in performing the functionality in 
bullets b, c and d above. 

f) UEs configured with a long minimum periodic PLMN search time limit (see TS 24.368 [69]) have an increased 
minimum time in between their searches for more preferred PLMNs. 

NOTE 1 : Following the failure of a more preferred PLMN, UEs configured as above might change to other local 
competing networks. Expiry of this search timer will lead to the UE re-attempting to access the failed 
network, and then, if that network has not yet recovered, reaccessing one of the local competing 
networks. Use of a too short timer for the more preferred PLMN search can both prevent the failed 
network from recovering, and, impose more load on the local competing networks. 

g) At PLMN change, UEs configured to perform Attach with IMSI at PLMN change (see TS 24.368 [69]) do this 
rather than a TA update with GUTI (thus avoiding the need to reject the TA update, and to request the IMSI 
following the subsequent Attach with GUTI). 

NOTE 2: In the case of a network failure, this reduces the message processing load on a local competing network 
and hence makes that network more likely to survive the failure of the other network. 

h) For mobile originated services, UEs configured for low access priority (see TS 24.368 [69]) provide a low access 
priority indication to the MME in NAS signalling that permit the MME to undertake protective measures (e.g. to 
permit the MME to immediately command the UE to move to a state where it does not need to generate further 
signalling messages and/or does not reselect PLMNs), as described in clause 4.3.7.4.1. 

i) Using Periodic TAU timer value sent by the HSS and/or UE provided indication (bullet h above), the MME can 
allocate a long periodic TAU timer value to the UE. A long periodic TAU timer is likely to slow down the rate at 
which a UE detects a network failure and thus it slows down the rate of movement of UEs from a failed network 
to other local competing networks (see clause 4.3.17.3). 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 42 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

j) Mechanisms for the MME and P-GW to detect congestion associated with a particular APN (see clauses 
4.3.7.4.2 and 4.3.7.5). 

k) The addition of 'back off timers' to EMM and ESM signalling messages (e.g. to rejection messages). These 

include some time randomisation to guard against a repeat of a load peak. The MME should be able to apply this 
behaviour on a per-APN basis, as described in clause 4.3.7.4.2 

1) Signalling that permits the P-GW to request the MME to generate the above ESM signalling with 'back off 
timers' (see clause 4.3.7.5). 

m) An MME overload control mechanism to selectively limit the number of Downlink Data Notification requests 
the S-GW sends to the MME for downlink low priority traffic received for UEs in idle mode (see 
clause 4.3.7.4. la). 

NOTE 3: It is assumed that the mechanisms described in this entire clause are designed by Stage 3 in a manner that 
allows extensibility and forward compatibility. 

4.3.1 7.3 Optimizing periodic TAU Signalling 

To reduce network load from periodic TAU signalling and to increase the time until the UE detects a potential need for 
changing the RAT or PLMN (e.g. due to network problems) the longer values of the periodic TAU timer and Mobile 
Reachable timer shall be supported. 

A long periodic RAU/TAU timer value may be locally configured at MME or may be stored as part of the subscription 
data in HSS. During Attach and TAU procedures the MME allocates the periodic RAU/TAU timer value as periodic 
TAU timer to the UE based on VPLMN operator policy, low access priority indication from the UE, and subscription 
information received from the HSS. 

If MME receives a subscribed periodic RAU/TAU timer value from the HSS it allocates the subscribed value to the UE 
as periodic TAU timer. A visited PLMN MME may use subscribed periodic RAU/TAU timer value, if available, as an 
indication to decide for allocating a locally configured periodic RAU/TAU timer value to the UE. 

4.3.1 7.4 UE configuration and usage of indicators 

A subscriber can by agreement with its operator be required to use UEs that are configured (see TS 24.368 [69]) to 
support one or more of the following options: 

MS configured for low access priority; and/or 

MS configured to perform Attach with IMS I at PLMN change; and/or 

MS configured with a long minimum periodic PLMN search time limit. 

NOTE 1 : When a UE is configured for low access priority, then the UE may be subject for longer backoff timers at 
overload and consequently need to be designed to be tolerant to delays when accessing the network. 

UEs can be configured for one or more of the above options. Post-manufacturing configuration of these options in the 
UE can be performed only by OMA DM or (U)SIM OTA procedures. UEs capable of the above options should support 
configuration of these options by both OMA DM and (U)SIM OTA procedures. 

A UE configured for low access priority shall transmit the low access priority indicator to the MME during the 
appropriate NAS signalling procedures and transmit the corresponding low access priority to the E-UTRAN during 
RRC connection establishment procedures. 

NOTE 2: The low access priority indicator in NAS signalling and the corresponding low access priority for RRC 
connection establishment are only used by the network to decide whether to accept the NAS request or 
the setup of the RRC connection respectively. 

Low access priority shall not be applicable in the following situations: 

for all procedures related to an emergency PDN connection; used for IMS Emergency sessions that are to be 
prioritized as per the requirements for IMS Emergency session procedures (see clause 4.3.12). When an 
emergency PDN connection gets established, the MME may, based on MME configuration, initiate the 
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deactivation of any non-emergency PDN connection using the MME requested PDN disconnection procedure 
described in clause 5.10.3; 

for all procedures when preferential access to the network is provided to the UE by the Access Class 11-15 
mechanism according to TS 36.331 [37] and TS 22.01 1 [67] e.g. for Multimedia Priority Services as described in 
clause 4.3.18; 

NOTE 3: The configuration of a UE for low access priority and Access Class 1 1-15 are configured independently 
of each other. However, the home operator can take care to prevent a subscription for Access Class 1 1-15 
from being used in a UE configured for low access priority. 

for RRC connection establishment procedures when responding to paging; or 

other specific situations described in TS 24.301 [46]. 

If the NAS session management request message used to establish a new PDN connection contains a low access priority 
indication, the MME shall forward the low access priority indication in the Create Session Request message to the S- 
GW/P-GW. The low priority indication gets associated with a PDN connection when it is established and it shall not 
change until the PDN connection is deactivated. 

The low access priority indication may be included in charging records by the visited and home networks. In order to 
permit the S-GW to include the low access priority indicator in the charging records, the low access priority indicator 
should be stored in the MME EPS Bearer contexts and should be passed as part of these contexts to other SGSN/MME 
or S-GW nodes in mobility management procedures. 

NOTE 4: In this release there is no other usage of storing the low access priority indicator in EPS Bearer contexts 
other than for the purpose to include it in charging records. Particularly, the low access priority indicator 
in EPS Bearer contexts is not used by the network to make overload control decisions. 

A network node may invoke one or more of the following mechanisms based on the indicators received in signalling 
from UEs or forwarded by other network nodes: 

based on the low access priority indicator in NAS request messages, bullets e, h, i, k and 1 as defined in 
clause 4.3.17.2; and/or 

based on the low access priority for RRC connection establishment, bullets b and c as defined in clause 4.3. 17.2. 

A UE shall invoke one or more of the following mechanisms based on the configuration and capabilities of the UE: 

when UE is configured with a long minimum periodic PLMN search time limit, the UE invokes actions as 
described in bullet f in clause 4.3. 17.2; and/or 

when UE is configured to perform Attach with IMSI at PLMN change invoke actions as described in bullet g in 
clause 4.3.17.2; and/or 

when a UE is configured for low access priority, the UE invokes actions as described in bullets b and h in 
clause 4.3.17.2; 

4.3.17.5 Void 



4.3.18 Multimedia Priority Service 
4.3.18.1 General 

Multimedia Priority Service (MPS) allows certain subscribers (i.e. Service Users as per TS 22.153 [68]) priority access 
to system resources in situations such as during congestion, creating the ability to deliver or complete sessions of a high 
priority nature. Service Users are government-authorized personnel, emergency management officials and/or other 
authorized users. MPS supports priority sessions on an "end-to-end" priority basis. 

MPS is based on the ability to invoke, modify, maintain and release sessions with priority, and deliver the priority 
media packets under network congestion conditions. MPS is supported in a roaming environment when roaming 
agreements are in place and where regulatory requirements apply. 
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NOTE 1: If a session terminates on a server in the Internet (e.g. web-based service), then the remote end and the 
Internet transport are out of scope for this specification. 

A Service User obtains priority access to the Radio Access Network by using the Access Class Barring mechanism 
according to TS 36.331 [37] and TS 22.011 [67]. This mechanism provides preferential access to UEs based on its 
assigned Access Class. If a Service User belongs to one of the special access-classes as defined in TS 22.01 1 [67], the 
UE has preferential access to the network compared to ordinary users in periods of congestion. 

MPS subscription allows users to receive priority services, if the network supports MPS. MPS subscription entitles a 
USIM with special Access Class(es). MPS subscription includes indication for support of EPS bearer priority service, 
IMS priority service and CS Fallback priority service support for the end user. Priority level regarding EPS bearer and 
IMS are also part of the MPS subscription information. The usage of priority level is defined in TS 23.203 [6] and 
TS 23.228 [52]. 

Service Users is treated as On Demand MPS subscribers or not, based on regional/national regulatory requirements. On 
Demand service is based on Service User invocation/revocation explicitly and applied to the PDN connections for an 
APN. When not On Demand, MPS service does not require invocation, and provides priority treatment for all EPS 
bearers for a given Service User after attachment to the EPS network. 

NOTE 2: Acording to regional/national regulatory requirements and operator policy, On-Demand MPS Service 
Users can be assigned the highest priority. 

For this release of the specification, MPS is supported for E-UTRAN access only in case of 3GPP accesses. 

Since the Service User has an access class within the range for priority services, the Establishment Cause in RRC 
connection request is set to highPriority Access. When the MME receives and verifies mobile initiated signalling with 
establishment cause set to highPriority Access, the MME and eNodeB prioritize RRC connection requests and establish 
the S 1 bearer and radio resources with priority. 

Priority treatment for MPS session requires appropriate ARP and QCI (where necessary for non-GBR bearers) setting 
for bearers according to the operator's policy. 

When an MPS session is requested by a Service User, the following bearer management principles apply in the 
network: 

EPS bearers (including default bearer) employed in an MPS session shall be assigned ARP value settings 
corresponding to the priority level of the Service User. 

Setting ARP pre-emption capability and vulnerability for MPS bearers, subject to operator policies and 
depending on national/regional regulatory requirements. 

Pre-emption of non-Service Users over Service Users during network congestion situation, subject to operator 
policy and national/regional regulations. 

Priority treatment is applicable to IMS based multimedia services, priority EPS bearer services (PS data without IMS 
interaction) and CS Fallback. 

For Multimedia Priority services any EPC functions, procedures and capabilities are provided according to clause this 
specification except when specified differently in the following subsections. 

4.3.1 8.2 IMS-based Multimedia Priority Services 
4.3.18.2.1 Originating IMS-based MPS Session 

IMS based MPS sessions are permitted to be originated from any UE, in addition to MPS-subscribed UEs. 

The MPS-subscribed UE, based on the MPS IMS subscription information, operator's policy and national/regional 
regulations, may be given priority treatment for the default bearer and the EPS bearer carrying IMS signalling in the 
EPS prior to and during IMS-based MPS invocation. Further, priority treatment in the EPS for signalling and media 
bearers may be modified/established via dynamic PCC based on the session authorization information received from the 
AF. 

As the IMS media bearer is established after the IMS session of the MPS service has been established, it can be 
assigned with correct ARP value when it is established. However IMS signalling related EPS bearer needs to be 
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upgraded if it has not been assigned with the appropriate ARP setting for the MPS service when the IMS session of the 
MPS service has been initiated. 

Also to avoid cases where the defauh bearer may not be allocated resources in the handover case, due to the low ARP 
priority for the MPS service related PDN connection, it is necessary to assure the ARP value of the default bearer 
receives the appropriate ARP setting for MPS service. 

4.3.18.2.2 Terminating IMS-based MPS Session 

The terminating network identifies the priority of the IMS-based MPS session and applies priority treatment to ensure 
that the call is delivered with priority to the terminating user (either a Service User or normal user). 

If the existing ARP of the default or dedicated EPS bearer that is used to transport IMS signalling are not appropriate 
for MPS, then PCRF updates to the appropriate settings. 

S-GW triggers a new priority paging towards MME in case the ongoing paging is lower priority than the incoming data 
received in the S-GW for IMS terminating session. 

4.3.1 8.3 Priority EPS Bearer Services 

The Service User receives on demand priority treatment according to its MPS profile, i.e. On-Demand. If the Service 
User is not authorized to use on-demand priority request, the Service User receives priority treatment (i.e. appropriate 
ARP and QCI ) at initial attach for all bearers, based on user profile data stored in the HSS/SPR and authorized by the 
PCRF (see TS 23.203 [6], clause 7.2). 

An On-Demand Service User requires explicit invocation/revocation via SPR MPS user profile update, which 
communicates with PCC to upgrade/downgrade. Since MPS user profile are part of inputs for PCC rules, the update 
will trigger PCC rules modification, installation, (see TS 23.203 [6], clause 7.4.2). 

Based on MPS EPS priority subscription, MME can verify whether the UE is permitted to initiate the RRC connection 
with higher priority and handle the request preferentially comparing to other UEs not prioritized. 

An AF for MPS Priority Service is used to provide Priority EPS Bearer Services using network-initiated resource 
allocation procedures (via interaction with PCC) for originating accesses. 

NOTE: Use of 3rd party AF for MPS services for Service Users is outside the scope of 3GPP specification. 

4.3.18.4 CS fallback 

CS Fallback allows users to fallback to GERAN/UTRAN/lx RTT while in E-UTRAN access thus allowing the network 
to transfer the call towards GERAN/UTRAN CS domain. In order to ensure that a priority CSFB call to/from a service 
user is given proper priority treatment in the EPS, MPS subscription indicates the user's CS priority status, i.e. MPS CS 
Priority, which is provided to MME with user's subscription information. When the MME receives and verifies mobile 
initiated signalling with establishment cause set to highPriority Access, the MME and eNodeB prioritize RRC 
connection requests and establish the S 1 bearer and radio resources with priority. 

Details on the priority treatment of CSFB, see TS 23.272 [58]. 

4.3.19 Core Network node resolution 
4.3.19.1 General 

The indication of mapped or native GUTI shall be signalled by the UE to the MME as an explicit indication in Attach 
Request and TAU Request messages. The indication of mapped or native P-TMSI/RAI shall be signalled by the UE to 
the SGSN as an explicit indication in Attach Request and RAU Request messages. The MME/SGSN resolves the old 
MME/SGSN using old GUTI respective old P-TMSI/RAI sent in the Attach request and TAU/RAU request messages , 
and determines if the old GUTI or the old P-TMSI/RAI is mapped or native by one of the following two methods: 

Indication using most significant bit (MSB) in LAC and MME Group ID. 

- Explicit indication sent from UE to MME and SGSN. 
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4.3.1 9.2 MSB in LAC and MME Group ID 

For PLMNs deployed with such mechanism the MME differentiates between a GUMMEI mapped from P-TMSI/RAI 
and a native GUMMEI based on the value of most significant bit of the MME Group ID; i.e. the MSB is set to "0" then 
the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one, as specified in 
TS 23.003 [9]. 

For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI 
and a native P-TMSI/RAI based on the value of most significant bit of the LAC; i.e. the MSB is set to "1" then the 
P-TMSI/RAI is mapped from GUTI and if MSB is set to "0", the P-TMSI/RAI is a native one, as specified in 
TS 23.003 [9]. 

4.3.19.3 Explicit Indication 

For PLMNs deployed with such mechanism the MME differentiates between a GUTI mapped from P-TMSI/RAI or a 
native GUTI based on the explicit indication sent by the UE. 

For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI or 
a native P-TMSI/RAI based on the explicit indication sent by the UE. 

4.3.20 Relaying function 



4.3.20.1 



General 



The relaying function enables an operator to improve and extend the coverage area by having a Relay Node (RN) 
wirelessly connected to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA 
radio interface called the Un interface as specified in TS 36.300 [5]. 

The relaying function and use of RN/DeNB entities in a network is transparent to the operations of the UEs connected 
to it and associated core network entities (e.g. MME, S/P-GW, PCRF etc.) for the UEs. 

The relaying architecture is shown in figure 4.3.20.1-1. 
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Figure 4.3.20.1-1 : Relaying Architecture 

NOTE 1 : Impact to core network elements from the introduction of RNs and DeNB is minimized by reusing the 
existing nodes and protocols when interacting with the core network. 

NOTE 2: Functions of the MME for the RN and MME for the UE may be collocated in a single MME. 

The RN supports the eNB functionality like termination of the radio protocols of the E-UTRA radio interface and the S 1 
and X2 interfaces. The RN also supports a subset of the UE functionality and protocols to wirelessly connect to the 
DeNB. 
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In addition to supporting eNB functionality, the DeNB also embeds and provides the S-GW/P-GW-like functions 
needed for the RN operation. This includes creating a session for the RN and managing EPS bearers for the RN as 
shown in clause 4.3.20.4, as well as terminating the Sl-AP and Sll interfaces towards the MME serving the RN. Due to 
the proxy functionality, the DeNB appears as an MME (for SI), an eNB (for X2) and an S-GW to the RN. 

The RN and DeNB also perform mapping of signalling and data packets onto EPS bearers that are setup for the RN. 
The mapping is based on existing QoS mechanisms defined for the UE and the P-GW and are described in 
TS 36.300 [5]. 

4.3.20.2 RN startup and attach procedure 

4.3.20.2.1 General 

The startup procedure for the Relay node is based on the normal UE attach procedure and consists of the following two 
phases: 

Phase I: Attach for RN preconfiguration. 

- Phase II: Attach for RN operation (MME of the RN). 

4.3.20.2.2 Attach for RN preconfiguration 

The RN attaches to the E-UTRAN/EPC as a UE at power-up and retrieves initial configuration parameters, e.g. list of 
DeNB cells, from RN OAM. During the attch procedure, the MME selected for the RN performs the S-GW and P-GW 
selection & subscription verification towards HSS for the RN as for a normal UE. The RN subscription includes a 
specific APN configured for this phase of operation only and shall be reserved for RN only. 

The authentication of the RN acting as an UE is performed by the MME during the initial attach procedure (see Sec. 
4.3.20.2), using the information obtained from the HSS. 

After this operation is complete, the RN detaches from the network as an UE and triggers Phase II. 

4.3.20.2.3 Attach for RN operation 

The RN connects to a DeNB selected from the list acquired during Phase I to start relay operations. For this purpose, the 
normal attach procedure, with the following exceptions, is applied: 

The DeNB is aware of the MMEs that support RN functionality; 

The RN sends an RN indication to the DeNB, which the DeNB forwards, together with the IP address of the 
S-GW/P-GW function embedded in the DeNB to an MME supporting RN functionality within the Initial UE 

Message; 

- MME (RN) selects the S-GW/P-GW in DeNB for the RN based on the IP address included in the Initial UE 
Message (i.e. all GW selection and APN related procedures are bypassed during this phase); 

During the attach procedure, the MME (RN) authenticates the RN as an RN; only if the authentication is 
successful, it accepts the attach procedure and sets up a context with the DeNB. 

When relay function is enabled, MMEs in a pool should all have the same relaying function capability in order to have 
consistent support for functions such as redundancy, load balancing. 
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Figure 4.3.20.2-1 : RN attach procedure 

The detach procedure for the RN is the same as the normal UE detach procedure, though the RN should ensure that no 
UE is connected to the RN cells before detaching. 

It is up to RN implementation how it ensures no UE is connected. 



4.3.20.4 



DeNB E-RAB activation/modification 



This procedure is used by the DeNB to change the EPS bearer allocation for the RN. The procedure is the same as the 
normal network-initiated bearer activation/modification procedure with the exception that the S-GW/P-GW 
functionality (steps 1 and 6) is performed by the DeNB. 
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Figure 4.3.20.4-1 : DeNB-initiated bearer activation/modification procedure 

NOTE: It is up to implementation if and when the DeNB sets up and modifies EPS bearers for the RN, in addition 
to the initial bearer set up procedures at Attach. 



4.4 



Network elements 



4.4.1 E-UTRAN 

E-UTRAN is described in more detail in TS 36.300 [5]. 

In addition to the E-UTRAN functions described in TS 36.300 [5], E-UTRAN functions include: 
Header compression and user plane ciphering; 
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MME selection when no routing to an MME can be determined from the information provided by the UE; 

UL bearer level rate enforcement based on UE-AMBR and MBR via means of uplink scheduling 
(e.g. by limiting the amount of UL resources granted per UE over time); 

DL bearer level rate enforcement based on UE-AMBR; 

UL and DL bearer level admission control; 

Transport level packet marking in the uplink, e.g. setting the DiffServ Code Point, based on the QCI of the 
associated EPS bearer; 

ECN-based congestion control. 

4.4.2 MME 

MME functions include: 

- NAS signalHng; 

NAS signalling security; 

Inter CN node signalling for mobility between 3GPP access networks (terminating S3); 

UE Reachability in ECM-IDLE state (including control and execution of paging retransmission); 

Tracking Area list management; 

Mapping from UE location (e.g. TAI) to time zone, and signalling a UE time zone change associated with 
mobility, 

- PDN GW and Serving GW selection; 

MME selection for handovers with MME change; 

SGSN selection for handovers to 2G or 3G 3GPP access networks; 

Roaming (S6a towards home HSS); 

Authentication; 

Authorization; 

Bearer management functions including dedicated bearer establishment; 

Lawful Interception of signalling traffic; 

Warning message transfer function (including selection of appropriate eNodeB); 

UE Reachability procedures; 

Support Relaying function (RN Attach/Detach). 

NOTE: The Serving GW and the MME may be implemented in one physical node or separated physical nodes. 

The MME shall signal a change in UE Time Zone only in case of mobility and in case of UE triggered Service Request, 
PDN Disconnection and UE Detach. If the MME cannot determine whether the UE Time Zone has changed (e.g. the 
UE Time Zone is not sent by the old MME during MME relocation), the MME should not signal a change in UE Time 
Zone. A change in UE Time Zone caused by a regulatory mandated time change (e.g. daylight saving time or summer 
time change) shall not trigger the MME to initiate signalling procedures due to the actual change. Instead the MME 
shall wait for the UE's next mobility event or Service Request procedure and then use these procedures to update the UE 
Time Zone information in the PDN GW. 
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4.4.3 Gateway 

4.4.3.1 General 

Two logical Gateways exist: 

- Serving GW (S-GW); 

- PDN GW (P-GW). 

NOTE: The PDN GW and the Serving GW may be implemented in one physical node or separated physical 
nodes. 

4.4.3.2 Serving GW 

The Serving GW is the gateway which terminates the interface towards E-UTRAN. 

For each UE associated with the EPS, at a given point of time, there is a single Serving GW. 

The functions of the Serving GW, for both the GTP-based and the PMIP-based S5/S8, include: 

the local Mobility Anchor point for inter-eNodeB handover; 

sending of one or more "end marker" to the source eNodeB, source SGSN or source RNC immediately after 
switching the path during inter-eNodeB and inter-RAT handover, especially to assist the reordering function in 
eNodeB. 

Mobility anchoring for inter-3GPP mobility (terminating S4 and relaying the traffic between 2G/3G system and 
PDN GW); 

ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure; 

Lawful Interception; 

Packet routing and forwarding; 

Transport level packet marking in the uplink and the downlink, e.g. setting the DiffServ Code Point, based on the 
QCI of the associated EPS bearer; 

Accounting for inter-operator charging. For GTP-based S5/S8, the Serving GW generates accounting data per 
UE and bearer; 

Interfacing OFCS according to charging principles and through reference points specified in TS 32.240 [51]. 

Additional Serving GW functions for the PMIP-based S5/S8 are captured in TS 23.402 [2]. 

Connectivity to a GGSN is not supported. 

4.4.3.3 PDN GW 

The PDN GW is the gateway which terminates the SGi interface towards the PDN. 

If a UE is accessing multiple PDNs, there may be more than one PDN GW for that UE, however a mix of S5/S8 
connectivity and Gn/Gp connectivity is not supported for that UE simultaneously. 

PDN GW functions include for both the GTP-based and the PMIP-based S5/S8: 

Per-user based packet filtering (by e.g. deep packet inspection); 

Lawful Interception; 

UE IP address allocation; 

Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point, based on the 
QCI of the associated EPS bearer; 
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Accounting for inter-operator charging; 

UL and DL service level charging as defined in TS 23.203 [6] 

(e.g. based on SDFs defined by the PCRF, or based on deep packet inspection defined by local policy); 

Interfacing OFCS through according to charging principles and through reference points specified in 

TS 32.240 [51]. 

UL and DL service level gating control as defined in TS 23.203 [6]; 

UL and DL service level rate enforcement as defined in TS 23.203 [6] 
(e.g. by rate policing/shaping per SDF); 

- UL and DL rate enforcement based on APN-AMBR 

(e.g. by rate policing/shaping per aggregate of traffic of all SDFs of the same APN that are associated with Non- 
GBR QCIs); 

DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI 
(e.g. by rate policing/shaping); 

DHCPv4 (server and client) and DHCPv6 (client and server) functions; 

The network does not support PPP bearer type in this version of the specification. Pre-Release 8 PPP 
functionality of a GGSN may be implemented in the PDN GW; 

packet screening. 

Additionally the PDN GW includes the following functions for the GTP-based S5/S8: 

UL and DL bearer binding as defined in TS 23.203 [6]; 

UL bearer binding verification as defined in TS 23.203 [6]; 

Functionality as defined in RFC 4861 [32]; 

Accounting per UE and bearer. 

The P-GW provides PDN connectivity to both GERAN/UTRAN only UEs and E-UTRAN capable UEs using any of 
E-UTRAN, GERAN or UTRAN. The P-GW provides PDN connectivity to E-UTRAN capable UEs using E-UTRAN 
only over the S5/S8 interface. 

4.4.4 SGSN 

In addition to the functions described in TS 23.060 [7], SGSN functions include: 

Inter EPC node signalling for mobility between 2G/3G and E-UTRAN 3GPP access networks; 

- PDN and Serving GW selection: the selection of S-GW/P-GW by the SGSN is as specified for the MME; 
Handling UE Time Zone as specified for the MME; 

MME selection for handovers to E-UTRAN 3GPP access network. 

4.4.5 GERAN 

GERAN is described in more detail in TS 43.051 [15]. 

4.4.6 UTRAN 

UTRAN is described in more detail in TS 25.401 [16]. 
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4.4.7 PCRF 

4.4.7.1 General 

PCRF is the policy and charging control element. PCRF functions are described in more detail in TS 23.203 [6]. 

In non-roaming scenario, there is only a single PCRF in the HPLMN associated with one UE's IP-CAN session. The 
PCRF terminates the Rx interface and the Gx interface. 

In a roaming scenario with local breakout of traffic there may be two PCRFs associated with one UE's IP-CAN session: 

- H-PCRF that resides within the H-PLMN; 

- V-PCRF that resides within the V-PLMN. 

4.4.7.2 Home PCRF (H-PCRF) 

The functions of the H-PCRF include: 

terminates the Rx reference point for home network services; 

terminates the S9 reference point for roaming with local breakout; 

associates the sessions established over the multiple reference points (S9, Rx), for the same UE's IP-CAN 
session (PCC session binding). 

The functionahty of H-PCRF is described in TS 23.203 [6]. 

4.4.7.3 Visited PCRF (V-PCRF) 

The functions of the V-PCRF include: 

terminates the Gx and S9 reference points for roaming with local breakout; 

terminates Rx for roaming with local breakout and visited operator's Application Function. 
The functionality of V-PCRF is described in TS 23.203 [6]. 

4.4.8 PDN GW's associated AAA Server 

The PDN Gateway may interact with a AAA server over the SGi interface. This AAA Server may maintain information 
associated with UE access to the EPC and provide authorization and other network services. This AAA Server could be 
a RADIUS or Diameter Server in an external PDN network, as defined in TS 29.061 [38]. This AAA Server is logically 
separate from the HSS and the 3GPP AAA Server. 

4.4.9 HeNB subsystem 

A HeNB subsystem consists of a HeNB, optionally a HeNB GW and optionally a Local GW. 
The Local IP Access function is achieved using a Local GW (L-GW) colocated with the HeNB. 
Figure 4.4.9-1 illustrates LIPA architecture. 
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Figure 4.4.9-1 : LIPA architecture for l-ieNB using a local PDN connection 

NOTE 1 : The optional HeNB GW is not shown in the figure for simplicity. 

The HeNB subsystem is connected by means of the standard S 1 interface to the EPC (Evolved Packet Core), more 
specifically to the MME (Mobility Management Entity) by means of the Sl-MME interface and to the Serving Gateway 
(S-GW) by means of the Sl-U interface. When LIPA is activated, the L-GW has a S5 interface with the S-GW. 

NOTE 2: In this specification and for simplification the term eNodeB refers to the HeNB subsystem if the UE 
accesses the network via a HeNB unless stated otherwise. 

NOTE 3: Detailed functions of HeNB and HeNB GW are described in TS 36.300 [5]. 

The Local GW is the gateway towards the IP networks (e.g. residential/enterprise networks) associated with the HeNB. 
The Local GW has the following PDN GW functions: 

UE IP address allocation; 

DHCPv4 (server and client) and DHCPv6 (client and server) functions; 

Packet screening; 

Functionality as defined in RFC 4861 [32]. 

Additionally, the Local GW has the following functions: 

ECM-IDLE mode downlink packet buffering; 

- ECM-CONNECTED mode direct tunnelling towards the HeNB. 

4.4.10 DeNB 

DeNB function is described in more detail in TS 36.300 [5]. 

DeNB provides the necessary S/P-GW functions for the operation of RNs connected to the DeNB. 



4.5 



Void 
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4.6 EPS Mobility IVIanagement and Connection IVIanagement 
states 

4.6.1 General 

The EPS Mobility Management (EMM) states describe the Mobihty Management states that resuh from the mobihty 
management procedures e.g. Attach and Tracking Area Update procedures. 

Two EMM states are described in this document: 

- EMM-DEREGISTERED. 

- EMM-REGISTERED. 

NOTE 1: Other specifications may define more detailed EMM states (see e.g. TS 24.301 [46]). 
The EPS Connection Management (ECM) states describe the signalling connectivity between the UE and the EPC. 
Two ECM states are described in this document: 

- ECM-IDLE. 

- ECM-CONNECTED. 

NOTE 2: The ECM-CONNECTED and ECM-IDLE states used in this document correspond respectively to the 
EMM-CONNECTED and EMM-IDLE modes defined in TS 24.301 [46]. 

In general, the ECM and EMM states are independent of each other. Transition from EMM-REGISTERED to EMM- 
DEREGISTERED can occur regardless of the ECM state, e.g. by expUcit detach signalling in ECM-CONNECTED or 
by implicit detach locally in the MME during ECM-IDLE. However there are some relations, e.g. to transition from 
EMM-DEREGISTERED to EMM-REGISTERED the UE has to be in the ECM-CONNECTED state. 

4.6.2 Definition of main EPS Mobility Management states 

4.6.2.1 EMM-DEREGISTERED 

In the EMM-DEREGISTERED state, the EMM context in MME holds no valid location or routing information for the 
UE. The UE is not reachable by a MME, as the UE location is not known. 

In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an 
AKA procedure during every Attach procedure. 

During the successful Inter-RAT TAU/RAU/handover procedure and ISR activated is not indicated to the UE, the old 
S4 SGSN/old MME changes the EMM state of the UE to GPRS-IDLE/PMM-DETACHED/EMM-DEREGISTERED. 

4.6.2.2 EMM-REGISTERED 

The UE enters the EMM-REGISTERED state by a successful registration with an Attach procedure to either E-UTRAN 
or GERAN/UTRAN. The MME enters the EMM-REGISTERED state by a successful Tracking Area Update procedure 
for a UE selecting an E-UTRAN cell from GERAN/UTRAN or by an Attach procedure via E-UTRAN. In the EMM- 
REGISTERED state, the UE can receive services that require registration in the EPS. 

NOTE: The UE employs a single combined state machine for EMM and GMM states. 

The UE location is known in the MME to at least an accuracy of the tracking area list allocated to that UE (excluding 
some abnormal cases). 

In the EMM-REGISTERED state, the UE shall: 

always have at least one active PDN connection; 

- setup the EPS security context. 
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After performing the Detach procedure, the state is changed to EMM-DEREGISTERED in the UE and in the MME. 
Upon receiving the TAU Reject and Attach Reject messages the actions of the UE and MME depend upon the 'cause 
value' in the reject message, but, in many cases the state is changed to EMM-DEREGISTERED in the UE and in the 
MME. 

If all the bearers belonging to a UE are released (e.g., after handover from E-UTRAN to non-3GPP access), the MME 
shall change the MM state of the UE to EMM-DEREGISTERED. If the UE camps on E-UTRAN and the UE detects 
that all of its bearers are released, the UE shall change the MM state to EMM-DEREGISTERED. If all the bearers (PDF 
contexts) belonging to a UE are released, while the UE camps on GERAN/UTRAN, the UE shall deactivate ISR by 
setting its TIN to "P-TMSI" as specified in TS 23.060 [7]. This ensures that the UE performs Tracking Area Update 
when it re-selects E-UTRAN. If the UE switches off its E-UTRAN interface when performing handover to non-3GPP 
access, the UE shall automatically change its MM state to EMM-DEREGISTERED. 

The MME may perform an implicit detach any time after the Implicit Detach timer expires. The state is changed to 
EMM-DEREGISTERED in the MME after performing the implicit detach. 

4.6.3 Definition of EPS Connection Management states 

4.6.3.1 ECM-IDLE 

A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, 
a UE performs cell selection/reselection according to TS 36.304 [34] and PLMN selection according to TS 23.122 [10]. 

There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U 
connection for the UE in the ECM-IDLE state. 

In the EMM-REGISTERED and ECM-IDLE state, the UE shall: 

perform a tracking area update if the current TA is not in the list of TAs that the UE has received from the 
network in order to maintain the registration and enable the MME to page the UE; 

perform the periodic tracking area updating procedure to notify the EPC that the UE is available; 

perform a tracking area update if the RRC connection was released with release cause "load balancing TAU 
required"; 

perform a tracking area update when the UE reselects an E-UTRAN cell and the UE's TIN indicates "P-TMSI"; 

perform a tracking area update for a change of the UE's Core Network Capability information or the UE specific 
DRX parameter; 

perform a tracking area update when the UE manually selects a CSG cell, and the CSG ID of that cell is absent 
from both the UE's Allowed CSG list and the UE's Operator CSG list; 

answer to paging from the MME by performing a service request procedure; 

perform the service request procedure in order to establish the radio bearers when uplink user data is to be sent. 

The UE and the MME shall enter the ECM-CONNECTED state when the signalling connection is established between 
the UE and the MME. Initial NAS messages that initiate a transition from ECM-IDLE to ECM-CONNECTED state are 
Attach Request, Tracking Area Update Request, Service Request or Detach Request. 

When the UE is in ECM-IDLE state, the UE and the network may be unsynchronized, i.e. the UE and the network may 
have different sets of established EPS bearers. When the UE and the MME enter the ECM-CONNECTED state, the set 
of EPS Bearers is synchronized between the UE and network. 

4.6.3.2 ECM-CONNECTED 

The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the 
handover procedure. 

The UE performs the tracking area update procedure when the TAI in the EMM system information is not in the list of 
TA's that the UE registered with the network, or when the UE handovers to an E-UTRAN cell and the UE's TIN 
indicates "P-TMSI". 
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For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The 
signalling connection is made up of two parts: an RRC connection and an S1_MME connection. 

The UE shall enter the ECM-IDLE state when its signalling connection to the MME has been released or broken. This 
release or failure is explicitly indicated by the eNodeB to the UE or detected by the UE. 

The SI release procedure changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE. 

NOTE 1 : The UE may not receive the indication for the S 1 release, e.g. due to radio link error or out of coverage. 
In this case, there can be temporal mismatch between the ECM-state in the UE and the ECM-state in the 
MME. 

After a signalling procedure, the MME may decide to release the signalling connection to the UE, after which the state 
at both the UE and the MME is changed to ECM-IDLE. 

NOTE 2: There are some abnormal cases where the UE transitions to ECM-IDLE. 

When a UE changes to ECM-CONNECTED state and if a radio bearer cannot be established, or the UE cannot 
maintain a bearer in the ECM-CONNECTED state during handovers, the corresponding EPS bearer is deactivated. 

4.6.4 State transition and functions 
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Figure 4.6.4-1 : EMM state model in UE 
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Figure 4.6.4-2: EMM state model in MME 
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Figure 4.6.4-3: ECM state model in UE 
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Figure 4.6.4-4: ECM state model in MME 



4.7 Overall QoS concept 

4.7.1 PDN connectivity service 

The Evolved Packet System provides IP connectivity between a UE and a PLMN external packet data network. This is 
referred to as PDN Connectivity Service. 

The PDN Connectivity Service supports the transport of traffic flow aggregate(s), consisting of one or more Service 
Data Flows (SDFs). 

NOTE: The concept of SDF is defined in the context of PCC, TS 23.203 [6], and is not explicitly visible in the 
NAS signalHng. 

4.7.2 The EPS bearer 



4.7.2.1 



The EPS bearer in general 



For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer for GTP-based S5/S8, and 
by an EPS bearer concatenated with IP connectivity between Serving GW and PDN GW for PMIP-based S5/S8. 

An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PDN GW for 
GTP-based S5/S8, and between UE and Serving GW for PMIP-based S5/S8. The packet filters signalled in the NAS 
procedures are associated with a unique packet filter identifier on per-PDN connection basis. 

NOTE 1 : The EPS Bearer Identity together with the packet filter identifier is used to reference which packet filter 
the UE intends to modify or delete, i.e. it is used to implement the unique packet filter identifier. 

The EPS bearer traffic flow template (TFT) is the set of all packet filters associated with that EPS bearer. 

An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic mapped 
to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue 
management policy, rate shaping policy, RLC configuration, etc.). Providing different bearer level packet forwarding 
treatment requires separate EPS bearers. 

NOTE 2: In addition but independent to bearer level QoS control, the PCC framework allows an optional 

enforcement of service level QoS control on the granularity of SDFs independent of the mapping of SDFs 
to EPS bearers. 

One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of 
the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the 
default bearer. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated 
bearer. 

An UpLink Traffic Flow Template (UL TFT) is the set of uplink packet filters in a TFT. A DownLink Traffic Flow 
Template (DL TFT) is the set of downlink packet filters in a TFT. Every dedicated EPS bearer is associated with a TFT. 
The UE uses the UL TFT for mapping traffic to an EPS bearer in the uplink direction. The PCEF (for GTP-based 
S5/S8) or the BBERF (for PMIP-based S5/S8) uses the DL TFT for mapping traffic to an EPS bearer in the downlink 
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direction. The UE may use the UL TFT and DL TFT to associate EPS Bearer Activation or Modification procedures to 
an application and to traffic flow aggregates of the application. Therefore the PDN GW shall, in the Create Dedicated 
Bearer Request and the Update Bearer Request messages, provide all available traffic flow description information (e.g. 
source and destination IP address and port numbers and the protocol information). 

For the UE, the evaluation precedence order of the packet filters making up the UL TFTs is signalled from the P-GW to 
the UE as part of any appropriate TFT operations. 

NOTE 3: The evaluation precedence index of the packet filters associated with the default bearer, in relation to 
those associated with the dedicated bearers, is up to operator configuration. It is possible to "force" 
certain traffic onto the default bearer by setting the evaluation precedence index of the corresponding 
filters to a value that is lower than the values used for filters associated with the dedicated bearers. It is 
also possible use the default bearer for traffic that does not match any of the filters associated with the 
dedicated bearers. In this case, the evaluation precedence index of the corresponding filter(s) (e.g., a 
"match all filter") need to be set to a value that is higher than the values used for filters associated with 
dedicated bearers. 

A unidirectional EPS bearer is either associated with an UL TFT or a DL TFT that matches the unidirectional traffic 
flow(s) and a DL TFT or an UL TFT in the other direction that blocks all traffic flows. 

The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on subscription 
data (in E-UTRAN the MME sets those initial values based on subscription data retrieved from HSS). 

In a non-roaming scenario, the PCEF may change the QoS parameter value received from the MME based on 
interaction with the PCRF or based on local configuration. When the PCEF changes those values, the MME shall use 
the bearer level QoS parameter values received on the S 1 1 reference point during establishment or modification of the 
default bearer. 

In a roaming scenario, based on local configuration, the MME may downgrade the ARP or APN-AMBR and/or remap 
QCI parameter values received from HSS to the value locally configured in MME (e.g. when the values received from 
HSS do not comply with services provided by the visited PLMN). The PCEF may change the QoS parameter values 
received from the MME based on interaction with the PCRF or based on local configuration. Alternatively, the PCEF 
may reject the bearer establishment. 

NOTE 4: For certain APNs (e.g. the IMS APN defined by the GSMA) the QCI value is strictly defined and 
therefore remapping of QCI is not permitted. 

NOTE 5: In roaming scenarios, the ARP/APN-AMBR/QCI values provided by the MME for a default bearer may 
deviate from the subscribed values depending on the roaming agreement. If the PCC/PCEF rejects the 
establishment of the default bearer, this implies that Attach via E-UTRAN will fail. Similarly, if the 
PCEF (based on interaction with the PCRF or based on local configuration) upgrades the ARP/APN- 
AMBR/QCI parameter values received from the MME, the default bearer establishment and attach may 
be rejected by the MME. 

NOTE 6: Subscription data related to bearer level QoS parameter values retrieved from the HSS are not applicable 
for dedicated bearers. 

For of E-UTRAN, the decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer 
level QoS parameter values are always assigned by the EPC. 

The MME shall not modify the bearer level QoS parameter values received on the S 1 1 reference point during 
establishment or modification of a default or dedicated bearer. Instead, the MME shall only transparently forwards 
those values to the E-UTRAN. Consequently, "QoS negotiation" between the E-UTRAN and the EPC during default or 
dedicated bearer establishment / modification is not supported. The MME may, however, reject the establishment or 
modification of a default or dedicated bearer (e.g. if the bearer level QoS parameter values sent by the PCEF over a 
GTP based S8 roaming interface do not comply with a roaming agreement). 

The distinction between default and dedicated bearers should be transparent to the access network (e.g. E-UTRAN). 

An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) 
value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the 
eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer. 

NOTE 7: Admission control can be performed at establishment / modification of a Non-GBR bearer even though a 
Non-GBR bearer is not associated with a GBR value. 
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A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer. 

NOTE 8: A default bearer provides the UE with IP connectivity throughout the lifetime of the PDN connection. 
That motivates the restriction of a default bearer to bearer type Non-GBR. 

The UE routes uplink packets to the different EPS bearers based on uplink packet filters in the TFTs assigned to these 
EPS bearers. The UE evaluates for a match, first the uplink packet filter amongst all TFTs that has the lowest evaluation 
precedence index and, if no match is found, proceeds with the evaluation of uplink packet filters in increasing order of 
their evaluation precedence index. This procedure shall be executed until a match is found or all uplink packet filters 
have been evaluated. If a match is found, the uplink data packet is transmitted on the EPS bearer that is associated with 
the TFT of the matching uplink packet filter. If no match is found, the uplink data packet shall be sent via the EPS 
bearer that has not been assigned any uplink packet filter. If all EPS bearers (including the default EPS bearer for that 
PDN) have been assigned one or more uplink packet filters, the UE shall discard the uplink data packet. 



4.7.2.2 



The EPS bearer with GTP-based S5/S8 




Radio Bearer 



S1 Bearer 



S5/S8 Bearer 



Figure 4.7.2.2-1 : Two Unicast EPS bearers (GTP-based S5/S8) 

An EPS bearer is realized by the following elements: 

In the UE, the UL TFT maps a traffic flow aggregate to an EPS bearer in the uplink direction; 

In the PDN GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in the downlink direction; 

A radio bearer (defined in TS 36.300 [5]) transports the packets of an EPS bearer between a UE and an eNodeB. 
If a radio bearer exists, there is a one-to-one mapping between an EPS bearer and this radio bearer; 

An S 1 bearer transports the packets of an EPS bearer between an eNodeB and a Serving GW; 

An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an S 1 bearer and the corresponding 
radio bearer, as defined in TS 36.300 [5]. 

An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW; 

A UE stores a mapping between an uplink packet filter and a radio bearer to create the mapping between a traffic 
flow aggregate and a radio bearer in the uplink; 

A PDN GW stores a mapping between a downlink packet filter and an S5/S8 bearer to create the mapping 
between a traffic flow aggregate and an S5/S8 bearer in the downlink; 

An eNodeB stores a one-to-one mapping between a radio bearer and an S 1 Bearer to create the mapping between 
a radio bearer and an S 1 bearer in both the uplink and downlink; 
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A Serving GW stores a one-to-one mapping between an SI Bearer and an S5/S8 bearer to create the mapping 
between an S 1 bearer and an S5/S8 bearer in both the upHnk and downHnk. 

The PDN GW routes downHnk packets to the different EPS bearers based on the downlink packet fihers in the TFTs 
assigned to the EPS bearers in the PDN connection. Upon reception of a downlink data packet, the PDN GW evaluates 
for a match, first the downlink packet filter that has the lowest evaluation precedence index and, if no match is found, 
proceeds with the evaluation of downlink packet filters in increasing order of their evaluation precedence index. This 
procedure shall be executed until a match is found, in which case the downlink data packet is tunnelled to the Serving 
GW on the EPS bearer that is associated with the TFT of the matching downlink packet filter. If no match is found, the 
downlink data packet shall be sent via the EPS bearer that does not have any downlink packet filter assigned. If all EPS 
bearers (including the default EPS bearer for that PDN) have been assigned a downlink packet filter, the PDN GW shall 
discard the downlink data packet. 

4.7.2.3 The EPS bearer with PMIP-based S5/S8 

See clause 4.10.3 in TS 23.402 [2]. 



4.7.3 Bearer level QoS parameters 



The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR, described in this clause. This clause 
also describes QoS parameters which are applied to an aggregated set of EPS Bearers: APN-AMBR and UE-AMBR. 

Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters: 

- QoS Class Identifier (QCI); 

Allocation and Retention Priority (ARP). 

A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet 
forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol 
configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNodeB). A one-to- 
one mapping of standardized QCI values to standardized characteristics is captured TS 23.203 [6]. 

NOTE 1: On the radio interface and on SI, each PDU (e.g. RLC PDU or GTP-U PDU) is indirectly associated with 
one QCI via the bearer identifier carried in the PDU header. The same applies to the S5 and S8 interfaces 
if they are based on GTP. 

The ARP shall contain information about the priority level (scalar), the pre-emption capability (flag) and the pre- 
emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification 
request can be accepted or needs to be rejected due to resource limitations (typically available radio capacity for GBR 
bearers). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with 
the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to 
drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP 
defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre- 
emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption 
capable bearer with a higher ARP priority value. Once successfully established, a bearer's ARP shall not have any 
impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding 
treatment should be solely determined by the other EPS bearer QoS parameters: QCI, GBR and MBR, and by the 
AMBR parameters. The ARP is not included within the EPS QoS Profile sent to the UE. 

NOTE 2: The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention, 
and Priority" . 

NOTE 3: Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values 
for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video 
to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNodeB can then drop 
the "video bearer" without affecting the "voice bearer". This would improve service continuity. 

NOTE 4: The ARP may also be used to free up capacity in exceptional situations, e.g. a disaster situation. In such a 
case the eNodeB may drop bearers with a lower ARP priority level to free up capacity if the pre-emption 
vulnerability information allows this. 

Each GBR bearer is additionally associated with the following bearer level QoS parameters: 
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- Guaranteed Bit Rate (GBR); 

- Maximum Bit Rate (MBR). 

The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can 
be expected to be provided by a GBR bearer (e.g. excess traffic may get discarded by a rate shaping function). See 
clause 4.7.4 for further details on GBR and MBR. 

Each APN access, by a UE, is associated with the following QoS parameter: 

- per APN Aggregate Maximum Bit Rate (APN-AMBR). 

The APN-AMBR is a subscription parameter stored per APN in the HSS. It limits the aggregate bit rate that can be 
expected to be provided across all Non-GBR bearers and across all PDN connections of the same APN (e.g. excess 
traffic may get discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilize the entire 
APN-AMBR, e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of 
APN-AMBR. The P-GW enforces the APN-AMBR in downhnk. Enforcement of APN-AMBR in uphnk is done in the 
UE and additionally in the P-GW. 

NOTE 5: All simultaneous active PDN connections of a UE that are associated with the same APN shall be 
provided by the same PDN GW (see clauses 4.3.8.1 and 5.10.1). 

Each UE in state EMM-REGISTERED is associated with the following bearer aggregate level QoS parameter: 

- per UE Aggregate Maximum Bit Rate (UE-AMBR). 

The UE-AMBR is limited by a subscription parameter stored in the HSS. The MME shall set the UE-AMBR to the sum 
of the APN-AMBR of all active APNs up to the value of the subscribed UE-AMBR. The UE-AMBR limits the 
aggregate bit rate that can be expected to be provided across all Non-GBR bearers of a UE (e.g. excess traffic may get 
discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilize the entire UE-AMBR, 
e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE AMBR. The 
E-UTRAN enforces the UE-AMBR in uplink and downlink. 

The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/ APN-AMBR denote bit rates of traffic per 
group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of 
the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-U/IP header overhead of the tunnel on S1_U. 

The HSS defines, for each PDN subscription context, the 'EPS subscribed QoS profile' which contains the bearer level 
QoS parameter values for the default bearer (QCI and ARP) and the subscribed APN-AMBR value. The subscribed 
ARP shall be used to set the priority level of the EPS bearer parameter ARP for the default bearer while the pre-emption 
capability and the pre-emption vulnerability information for the default bearer are set based on MME operator policy. In 
addition, the subscribed ARP shall be applied by the P-GW for setting the ARP priority level of all dedicated EPS 
bearers of the same PDN connection unless a specific ARP priority level setting is required (due to P-GW configuration 
or interaction with the PCRF). 

NOTE 6: The ARP parameter of the EPS bearer can be modified by the P-GW (e.g. based on interaction with the 
PCRF) to assign the appropriate pre-emption capability and the pre-emption vulnerability setting. 

The ARP pre-emption vulnerability of the default bearer should be set appropriately to minimize the risk of unnecessary 
release of the default bearer. 

4.7.4 Support for Application / Service Layer Rate Adaptation 

The E-UTRAN/UTRAN and the UE support the RFC 3168 [55] Explicit Congestion Notification (ECN), as described 
in TS 36.300 [5], TS 25.401 [16] and TS 26.114 [56]. The IP level ECN scheme enables the E-UTRAN/UTRAN to 
trigger a rate adaptation scheme at the application / service / transport layer. To make sufficient time available for end- 
to-end codec rate adaptation the E-UTRAN/UTRAN should attempt to not drop any packets on a bearer for a default 
grace period of at least 500 ms after it has indicated congestion with ECN on the bearer for packets within the packet 
delay budget. During this ECN grace period the E-UTRAN/UTRAN should also attempt to meet the QCI characteristics 
/ QoS class associated with the bearer. 

NOTE 1 : Note that the receiving end-point should interpret all ECN-CE signals received within one end-to-end 
round-trip time as one "congestion event" (see IETF RFC 3168 [55] and TS 26.114 [56]). 
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The MBR of a particular GBR bearer may be set larger than the GBR. 

NOTE 2: Enforcement of APN-AMBR / UE-AMBR is independent of whether the MBR of a particular GBR 
bearer has been set larger than the GBR (see clause 4.7.3). 

The EPC does not support E-UTRAN/UTRAN-initiated "QoS re-negotiation". That is, the EPC does not support an 
eNodeB/RNC initiated bearer modification procedure. If an eNodeB/RNC can no longer sustain the GBR of an active 
GBR bearer then the eNodeB/RNC should simply trigger a deactivation of that bearer. 

4.7.5 Application of PCC in tine Evolved Packet System 

The Evolved Packet System applies the PCC framework as defined in TS 23.203 [6] for QoS policy and charging 
control. PCC functionality is present in the AF, PCEF and PCRF. 

An EPS needs to support both PCEF and PCRF functionality to enable dynamic policy and charging control by means 
of installation of PCC rules based on user and service dimensions. However, an EPS may only support PCEF 
functionality in which case it shall support static policy and charging control. 

NOTE: The local configuration of PCEF static policy and charging control functionality is not subject to 
standardization. The PCEF static policy and control functionality is not based on subscription 
information. 

The following applies to the use of dynamic policy and charging control in EPS: 

The service level (per SDF) QoS parameters are conveyed in PCC rules (one PCC rule per SDF) over the Gx 
reference point. The service level QoS parameters consist of a QoS Class Identifier (QCI) Allocation and 
Retention Priority (ARP) and authorised Guaranteed and Maximum Bit Rate values for uplink and downlink. 
The QCI is a scalar that represents the QoS characteristics that the EPS is expected to provide for the SDF. ARP 
is an indicator of the priority for the SDF that is used to decide about the assignment of resources due to resource 
limitations. The service level ARP assigned by PCRF in a PCC rule may be different from the bearer level ARP 
stored in subscription data; 

The set of standardized QCIs and their characteristics that the PCRF in an EPS can select from is provided in 
TS 23.203 [6]. It is expected that the PCRF selects a QCI in such a way that the IP-CAN receiving it can support 
it; 

It is not required that an IP-CAN supports all standardized QCIs; 

In the case of IP address configuration subsequent to initial attachment, i.e. through DHCP mechanism to 
complete the IP address configuration, the PDN GW/PCEF shall notify the PCRF of the UE's IP address by 
means of an IP -CAN Session Modification procedure or IP-CAN Session Establishment procedure as defined in 
TS 23.203 [6] when it is assigned. If the PCRF response leads to an EPS bearer modification the PDN GW 
should initiate a bearer update procedure; 

For local breakout, the visited network has the capability to reject the QoS authorized by the home network 
based on operator policies. 

The following applies regardless of whether dynamic or static policy and charging control is used in EPS: 

- For E-UTRAN the value of the ARP of an EPS bearer is identical to the value of the ARP of the SDF(s) mapped 
to that EPS bearer; 

For the same UE/PDN connection: SDFs associated with different QCIs or with the same service-level QCI but 
different ARP shall not be mapped to the same EPS bearer; 

The bearer level QCI of an EPS bearer is identical to the value of the QCI of the SDF(s) mapped to that EPS 
bearer. 
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4.8 Compatibility Issues 

4.8.1 Network Configuration for Interaction with UTRAN/GERAN 

GPRS idle mode mobility within GERAN or UTRAN and also between GERAN and UTRAN specifies a set of 
sequence number handling functions, e.g. the exchange of sequence numbers during Routing Area Update procedures. 
EPS idle mode mobility procedures don't specify any such sequence number mappings for IRAT mobility scenarios. To 
avoid interoperation issues a network that deploys E-UTRAN together with GERAN and/or UTRAN shall not configure 
usage of the GPRS feature "reordering required" for PDP contexts of PDP type IPv4, IPv6 or IPv4v6. Also the network 
shall not configure usage of lossless PDCP of UTRAN and the GERAN SGSN shall not configure usage of 
acknowledged mode LLC/NSAPI/SNDCP. 

5 Functional description and information flows 

5.1 Control and user planes 

5.1.0 General 

NOTE: 

- Refer to TS 23.402 [2] for the corresponding protocol stack for PMIP based S5/S8. 

Refer to TS 23.203 [6] for the corresponding protocol stack for Policy Control and Charging (PCC) 
function related reference points. 

5.1.1 Control Plane 
5.1.1.1 General 

The control plane consists of protocols for control and support of the user plane functions: 

controlling the E-UTRA network access connections, such as attaching to and detaching from E-UTRAN; 

controlling the attributes of an established network access connection, such as activation of an IP address; 

controlling the routing path of an established network connection in order to support user mobility; and 

controlling the assignment of network resources to meet changing user demands. 
The following control planes are used in E-UTRAN mode. 
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5.1.1.2 
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Legend: 



SI Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME. 
SCTP for the control plane (SCTP): This protocol guarantees delivery of signalling messages between 
MME and eNodeB (SI). SCTP is defined in RFC 4960 [35]. 



Figure 5.1.1.2-1: Control Plane for S1-MME Interface 

NOTE: Refer to TS 36.300 [5] for the corresponding control plane for the HeNB Subsystem - MME. 

5.1.1.3 UE-MME 
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NAS: The NAS protocol supports mobility management functionality and user plane bearer activation, 
modification and deactivation. It is also responsible of ciphering and integrity protection of NAS signalling. 
LTE-Uu: The radio protocol of E-UTRAN between the UE and the eNodeB is specified in TS 36.300 [5]. 

Figure 5.1 .1 .3-1 : Control Plane UE - MME 
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5.1.1.4 
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Legend: 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between SGSN and MME {S3). 

User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in 
RFC 768 [26]. 



Figure 5.1.1.4-1 : Control Plane for S3 Interface 
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Legend: 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between SGSN and S-GW (S4). 

User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in 
RFC 768 [26]. 



Figure 5.1.1.5-1 : Control Plane for S4 interface 
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5.1.1.6 
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Legend: 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between S-GW and P-GW {S5 or S8). 

User Datagram Protocol (UDP): This protocol transfers signalling messages between S-GW and P-GW. 
UDP is defined in RFC 768 [26]. 



Figure 5.1.1.6-1 : Control Plane for S5 and S8 interfaces 



5.1.1.7 



MME-MME 



GTP-C 






GTP-C 






UDP 


UDP 






IP 


IP 






L2 


L2 






LI 


L1 







S10 



MME 



MME 



Legend: 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between MMEs(S10). 

User Datagram Protocol (UDP): This protocol transfers signalling messages between IVIMEs. UDP is 
defined in RFC 768 [26]. 



Figure 5.1.1.7-1: Control Plane for SI interface 
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5.1.1.8 
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Legend: 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between MME and S-GW (S11). 

User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in 
RFC 768 [26]. 



Figure 5.1 .1 .8-1 : Control Plane for S1 1 interface 



5.1.1.9 
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Legend: 



Diameter: This protocol supports transferring of subscription and authentication data for 
authenticating/authorizing user access to the evolved system between MME and HSS (S6a). Diameter is 
defined in RFC 3588 [31]. 

Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is 
defined in RFC 4960 [35]. 



Figure 5.1 .1 .9-1 : Control Plane for S6a interface 



£75/ 



3GPP TS 23.401 version 10.3.0 Release 10 



68 



ETSI TS 123 401 VI 0.3.0 (2011-03) 



5.1.1.10 MME-EIR 
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Legend: 



Diameter: This protocol supports UE identity checi< procedure between IVIIVIE and EIR (SI 3). Diameter is 
defined in RFC 3588 [31]. 

Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is 
defined in RFC 4960 [35]. 



Figure 5.1.1.10-1: Control Plane for SI 3 interface 
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SBc Application Protocol (SBc-AP): Application Layer Protocol between CBC and IVIME. This protocol 
supports transfer of warning messages. 

SI Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME. 
SCTP for the control plane( SCTP): This protocol guarantees delivery of signalling messages between 
MME and eNodeB (S1). SCTP is defined in RFC 4960 [35]. 



Figure 5.1.1.11-1: CBC -eNodeB 
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5.1.2 User Plane 



5.1.2.1 



UE - P-GW user plane with E-UTRAN 
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GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 

eNodeB and the S-GW as well as between the S-GW and the P-GW in the bacl<bone networl<. GTP shall 

encapsulate all end user IP packets. 

MME controls the user plane tunnel establishment and establishes User Plane Bearers between eNodeB 

and S-GW. 

UDP/IP: These are the backbone network protocols used for routing user data and control signalling. 

LTE-Uu: The radio protocols of E-UTRAN between the UE and the eNodeB are specified in TS 36.300 [5]. 

Figure 5.1.2.1-1: User Plane 



5.1.2.2 
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GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 

eNodeB and S-GW. 

User Datagram Protocol (UDP): This protocol transfers user data. UDP is defined in RFC 768 [26]. 



Figure 5.1 .2.2-1 : User Plane for eNodeB - S-GW 

NOTE: Refer to TS 36.300 [5] for the corresponding user plane for the HeNB Subsystem - S-GW. 
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5.1.2.3 
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UE - PDN GW user plane with 2G access via the S4 interface 
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GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between SGSN 
and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall 
encapsulate all end user IP packets. 

UDP/IP: These are the backbone network protocols used for routing user data and control signalling. 
Protocols on the Um and the Gb interfaces are described in TS 23.060 [7]. 

Figure 5.1 .2.3-1 : User Plane for A/Gb mode 
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5.1 .2.4 UE - PDN GW user plane with 3G access via the S1 2 interface 
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GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 

UTRAN and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall 

encapsulate all end user IP packets. 

UDP/IP: These are the backbone network protocols used for routing user data and control signalling. 

Protocols on the Uu interface are described in TS 23.060 [7]. 

SGSN controls the user plane tunnel establishment and establish a Direct Tunnel between UTRAN and 

S-GW as shown in Figure 5.1.2.4-1. 

Figure 5.1.2.4-1: User Plane for UTRAN mode and Direct Tunnel on S12 
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5.1 .2.5 UE - PDN GW user plane with 3G access via the S4 interface 
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NOTE: Please refer to TS 23.402 [2] for the corresponding staci< for PIVIIP based S5/S8. 



Legend: 



GPRS Tunnelling Protocol for the user plane (GTP-U): Tliis protocol tunnels user data between 

UTRAN and the SGSN, between SGSN and S-GW as well as between the S-GW and the P-GW in the 

backbone networl<. GTP shall encapsulate all end user IP pacl<ets. 

UDP/IP: These are the backbone network protocols used for routing user data and control signalling. 

Protocols on the Uu and the lu interfaces are described in TS 23.060 [7]. 

SGSN controls the user plane tunnel establishment and establishes a tunnel between SGSN and S-GW. If 

Direct Tunnel is established between UTRAN and S-GW, see Figure 5.1 .2.4-1 . 

Figure 5.1.2.5-1 : User Plane for lu mode 



5.2 



Identities 



5.2.1 EPS bearer identity 

An EPS bearer identity uniquely identifies an EPS bearer for one UE accessing via E-UTRAN. The EPS Bearer Identity 
is allocated by the MME. There is a one to one mapping between EPS RB and EPS Bearer, and the mapping between 
EPS RB Identity and EPS Bearer Identity is made by E-UTRAN. The E-RAB ID value used at SI and X2 interfaces to 
identify an E-RAB is the same as the EPS Bearer ID value used to identify the associated EPS Bearer. 

When there is a mapping between an EPS bearer and a PDP context, the same identity value is used for the EPS bearer 
ID and the NSAPI/RAB ID. 

In some SM signalling messages in GERAN/UTRAN, transaction identifier (TI) represents NSAPI. The TI is 
dynamically allocated by the UE for UE-requested PDP context activation, and by the network for network-requested 
PDP context activation. A corresponding allocation is also needed for EPS Bearers in order to successfully transfer 
Bearers to GERAN/UTRAN. The TI is deallocated when a PDP context/EPS Bearer has been deactivated. TI usage is 
defined in TS 23.060 [7]. 

5.2.2 Globally Unique Temporary UE Identity 

The MME shall allocate a Globally Unique Temporary Identity (GUTI) to the UE. The GUTI is defined in 
TS 23.003 [9]. 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 73 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

5.2.3 Tracking Area Identity (TAI) 

This is the identity used to identify tracking areas. The Tracking Area Identity is constructed from the MCC (Mobile 
Country Code), MNC (Mobile Network Code) and TAC (Tracking Area Code). 

A TAI should be associated with a single time zone. All TAIs served by one eNodeB shall be in the same time zone. 

NOTE: Changes in the TAI of a cell can occur but are normally infrequent and linked with O+M activity. 

5.2.4 eNodeB S1 -AP UE Identity (eNodeB S1 -AP UE ID) 

This is the temporary identity used to identify a UE on the Sl-MME reference point within the eNodeB. It is unique 
within the eNodeB. 

5.2.5 MME S1 -AP UE Identity (MME S1 -AP UE ID) 

This is the temporary identity used to identify a UE on the S 1-MME reference point within the MME. It is unique 
within the MME. 



5.2.6 Closed Subscriber Group ID 



A CSG ID is a unique identifier within the scope of PLMN defined in TS 23.003 [9] which identifies a Closed 
Subscriber Group (CSG) in the PLMN associated with a CSG cell or group of CSG cells. 

5.3 Authentication, security and location management 
5.3.1 IP address allocation 
5.3.1.1 General 

A UE shall perform the address allocation procedures for at least one IP address (either IPv4 address or IPv6 prefix) 
after the default bearer activation if no IPv4 address is allocated during the default bearer activation. 

One of the following ways shall be used to allocate IP addresses for the UE: 

a) The HPLMN allocates the IP address to the UE when the default bearer is activated (dynamic or static HPLMN 
address); 

b) The VPLMN allocates the IP address to the UE when the default bearer is activated (dynamic VPLMN address); 
or 

c) The PDN operator or administrator allocates an (dynamic or static) IP address to the UE when the default bearer 
is activated (External PDN Address Allocation). 

The IP address allocated for the default bearer shall also be used for the dedicated bearers within the same PDN 
connection. IP address allocation for PDN connections, which are activated by the UE requested PDN connectivity 
procedure, is handled with the same set of mechanisms as those used within the Attach procedure. 

PDN types IPv4, IPv6 and IPv4v6 are supported. An EPS Bearer of PDN type IPv4v6 may be associated with one IPv6 
prefix only or with both one IPv4 address and one IPv6 prefix. PDN type IPv4 is associated with an IPv4 address. PDN 
type IPv6 is associated with an IPv6 prefix. PDN types IPv4 and IPv6 are utilised for the UE and/or the PDN GW 
support IPv4 addressing only or IPv6 prefix only; or operator preferences dictate the use of a single IP version only, or 
the subscription is limited to IPv4 only or IPv6 only for this APN. In addition, PDN type IPv4 and IPv6 are utilised for 
interworking with nodes of earlier releases. 

The way that the UE sets the requested PDN type may be pre-configured in the device per APN. Unless otherwise 
configured (including when the UE does not send any APN), the UE sets the PDN type during the Attach or PDN 
Connectivity procedures based on its IP stack configuration as follows: 

A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6. 
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A UE which is only IPv4 capable shall request for PDN type IPv4. 

A UE which is only IPv6 capable shall request for PDN type IPv6. 

When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are 
separated and the capability of the TE is not known in the MT), the UE shall request for PDN type IPv4v6. 

The HSS stores one or more PDN types per APN in the subscription data. During the Attach or UE requested PDN 
connectivity procedure he MME compares the requested PDN type to the PDN type in the subscription records for the 
given APN and sets the PDN type as follows: 

If the requested PDN type is allowed by subscription, the MME sets the PDN type as requested. 

If the requested PDN type is IPv4v6 and subscription data only allows PDN type IPv4 or only allows PDN type 
IPv6, the MME sets the PDN type according to the subscribed value. A reason cause shall be returned to the UE 
indicating that only the assigned PDN type is allowed. In this case the UE shall not request another PDN 
connection to the same APN for the other IP version. 

If the requested PDN type is IPv4 or IPv6, and neither the requested PDN type nor PDN type IPv4v6 are 
subscribed, the PDN connection request is rejected. 

If the requested PDN type is IPv4v6, and both IPv4 and IPv6 PDN types are allowed by subscription but not 
IPv4v6, the MME shall set the PDN type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is 
implementation specific. The UE should then initiate the UE requested PDN connectivity procedure to this APN 
in order to activate a second PDN connection with the other single address PDN type which was not allocated by 
the network. 

NOTE 1: If the MT and TE are separated, the UE might not be able to use reason cause "single address bearers 
only" as a trigger for activating a second single-stack EPS bearer. 

The PDN GW may restrict the usage of a PDN type IPv4v6 as follows. 

If the PDN GW receives a request for PDN type IPv4v6, but the PDN GW operator preferences dictate the use of 
IPv4 addressing only or IPv6 prefix only for this APN, the PDN type shall be changed to a single address PDN 
type (IPv4 or IPv6) and a reason cause shall be returned to the UE indicating that only the assigned PDN type is 
allowed. In this case the UE shall not request another PDN connection to the same APN for the other IP version. 

If the PDN GW receives a request for PDN type IPv4v6, but the MME does not set the Dual Address Bearer 
Flag due to the MME operator using single addressing per bearer to support interworking with nodes of earlier 
releases the PDN type shall be changed to a single IP version only and a reason cause shall be returned to the UE 
indicating that only single IP version per PDN connection is allowed. In this case the UE should request another 
PDN connection for the other IP version using the UE requested PDN connectivity procedure to the same APN 
with a single address PDN type (IPv4 or IPv6) other than the one already activated. 

During inter-RAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4v6 shall be 
mapped one-to-one to PDP type IPv4v6. 

During inter-RAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4 shall be 
mapped one-to-one to a PDP context of PDP type IPv4. An EPS bearer with PDN type IPv6 shall be mapped one-to-one 
to a PDP context of PDP type IPv6. 

It is the HPLMN operator that shall define in the subscription whether a dynamic HPLMN or VPLMN address may be 
used. 

The EPS UE may indicate to the network within the Protocol Configuration Options element that the UE wants to 
obtain the IPv4 address with DHCPv4: 

the UE may indicate that it prefers to obtain an IPv4 address as part of the default bearer activation procedure. In 
such a case, the UE relies on the EPS network to provide IPv4 address to the UE as part of the default bearer 
activation procedure. 

the UE may indicate that it prefers to obtain the IPv4 address after the default bearer setup by DHCPv4. That is, 
when the EPS network supports DHCPv4 and allows that, it does not provide the IPv4 address for the UE as part 
of the default bearer activation procedures. The network may respond to the UE by setting the PDN Address to 
0.0.0.0. After the default bearer establishment procedure is completed, the UE uses the connectivity with the EPS 
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and initiates the IPv4 address allocation on its own using DHCPv4. However, if the EPS network provides IPv4 
address to the UE as part of the default bearer activation procedure, the UE should accept the IPv4 address 
indicated in the default bearer activation procedure. 

if the UE sends no Address Allocation Preference, the PDN GW determines whether to use DHCPv4 or not 
based on per APN configuration 

Both EPS network elements and UE shall support the following mechanisms: 

a. IPv4 address allocation via default bearer activation, if IPv4 is supported. 

b. /64 IPv6 prefix allocation via IPv6 Stateless Address autoconfiguration according to RFC 4862 [18], if IPv6 is 
supported; 

Furthermore, the Protocol Configuration Options may be used during bearer activation to configure parameters which 
are needed for IP address allocation. 

Both EPS network elements and UE may support the following mechanisms: 

a. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to 
RFC 2131 [19] and RFC 4039 [25]; 

b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736 [20]. 

c. Allocation of IPv6 prefixes using DHCPv6 according to RFC 3633 [21]. 
EPS network elements may support the following mechanism: 

a. Allocation of a static IPv4 address and/or a static IPv6 prefix based on subscription data in the HSS. 

If the static IP address/prefix is not stored in the HSS subscription record, it may be configured on a per-user per- APN 
basis in the DHCP/Radius/Diameter server and the PDN GW retrieves the IP address/prefix for the UE from the 
DHCP/Radius/Diameter server. In this case, static IP address/prefix is allocated by the same procedures as the dynamic 
IP address/prefix allocation. 

The following clauses describe how the above listed IP address allocation mechanisms work when GTP based S5/S8 is 

used. The way of working of the IP address allocation mechanisms for PMIP based S5/S8 can be found in 

TS 23.402 [2]. The procedures can be used both for PLMN (VPLMN/HPLMN) or external PDN based IP address 

allocation. 

NOTE 2: It is transparent to the UE whether the PLMN or the external PDN allocates the IP address and whether 
the IP address is static or dynamic. 

In order to support DHCP based IP address configuration, the PDN GW shall act as the DHCP server for HPLMN 
assigned dynamic and static and VPLMN assigned dynamic IP addressing. When DHCP is used for external PDN 
assigned addressing and parameter configuration, the PDN GW shall act as the DHCP server towards the UE and it 
shall act as the DHCP client towards the external DHCP server. The Serving GW does not have any DHCP 
functionality. It forwards packets, including DHCP packets, between the UE and the PDN GW. 

IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is the basic mechanism to allocate /64 IPv6 prefix 
to the UE. 

During default bearer establishment, the PDN GW sends the IPv6 prefix and Interface Identifier to the S-GW, and then 
the S-GW forwards the IPv6 prefix and Interface Identifier to the MME or to the SGSN. The MME or the SGSN 
forwards the IPv6 Interface Identifier to the UE. The MME does not forward the IPv6 prefix to the UE. If the UE 
receives the IPv6 prefix from the SGSN during PDP Context Activation procedure, it shall ignore it. 
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5.3.1 .2 IP address allocation, renewal and release mechanisms for GTP based 

S5/S8 

5.3.1 .2.1 IPv4 address allocation via default bearer activation and release via PDN 
connection release 

An IPv4 address may be provided to the UE as part of the default bearer activation and the IPv4 address is released 
when PDN connection associated with the IPv4 address is released. 

When the PLMN allocates an IPv4 address, it is the PDN GW responsibility to allocate and release the IPv4 address. 
The PDN GW may use an internal IPv4 address pool in this case. The PDN GW allocates an IPv4 address upon default 
bearer activation and it releases the IPv4 address upon PDN connection release associated with the IPv4 address for a 
given UE. 

NOTE: If the PDN type is IPv4v6, when the PDN Connection is released, the IPv6 address is also released. 

When an IPv4 address is allocated from an external PDN, it is the PDN GW responsibility to obtain the IPv4 address 
from the external PDN, and to allocate, renew and release the IPv4 address. The PDN GW may use DHCPv4 to obtain, 
renew and release the IPv4 address from the external PDN. If RADIUS or Diameter is used towards the external PDN, 
as described in TS 29.061 [38], the IP address can be obtained, renewed and released as part of these procedures. If 
DHCPv4 is used, the PDN GW functions as a DHCPv4 Client. If RADIUS is used, the PDN GW functions as a 
RADIUS Client. If Diameter is used, the PDN GW functions as a Diameter Client. 

After releasing the IPv4 address, the PDN GW should not assign that IPv4 address to other user immediately. 

5.3.1 .2.2 Allocation, renewal and release of the IPv6 default prefix via IPv6 stateless 
address autoconfiguration 

When the PLMN allocates an IPv6 prefix, it is the PDN GW responsibility to allocate and release the IPv6 prefix. The 
PDN GW may use an internal IPv6 prefix pool in this case. The PDN GW allocates a globally unique /64 IPv6 prefix 
via Router Advertisement to a given UE. 

When an IPv6 prefix is allocated from an external PDN, it is the PDN GW responsibility to obtain the IPv6 prefix from 
the external PDN and to allocate, renew and release the IPv6 prefix. The PDN GW may use DHCPv6 to obtain the IPv6 
prefix from the external PDN. In this case, the PDN GW functions as a DHCPv6 client. If RADIUS or Diameter is used 
towards the external PDN as described in TS 29.061 [38], the IPv6 prefix can be obtained, renewed and released as part 
of these procedures. If RADIUS is used, the PDN GW functions as the RADIUS Client. If Diameter is used, the PDN 
GW functions as the Diameter Client. 

The procedure of stateless IPv6 address autoconfiguration is the following: After default bearer establishment the UE 
may send a Router Solicitation message to the PDN GW to solicit a Router Advertisement message. The PDN GW 
sends a Router Advertisement message (solicited or unsolicited) to the UE. The Router Advertisement messages shall 
contain the same IPv6 prefix as the one provided during default bearer establishment. If the UE receives an IPv6 prefix 
from a SGSN during the PDP Context activation procedure, it shall ignore it. 

After the UE has received the Router Advertisement message, it constructs a full IPv6 address via IPv6 Stateless 
Address autoconfiguration in accordance with RFC 4862 [18]. To ensure that the link-local address generated by the 
UE does not collide with the link-local address of the PDN GW, the PDN GW shall provide an interface identifier (see 
RFC 4862 [18]) to the UE and the UE shall use this interface identifier to configure its link-local address. For stateless 
address autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses, other than 
link-local, without involving the network. However, the UE shall not use any identifiers defined in TS 23.003 [9] as the 
basis for generating the interface identifier. For privacy, the UE may change the interface identifier used to generate full 
IPv6 address, as defined in TS 23.221 [27] without involving the network. 

Any prefix that the PDN GW advertises to the UE is globally unique. The PDN GW shall also record the relationship 
between the UE's identity (IMSI) and the allocated IPv6 prefix. Because any prefix that the PDN GW advertises to the 
UE is globally unique, there is no need for the UE to perform Duplicate Address Detection for any IPv6 address 
configured from the allocated IPv6 prefix. Even if the UE does not need to use Neighbor Solicitation messages for 
Duplicate Address Detection, the UE may, for example, use them to perform Neighbor Unreachability Detection 
towards the PDN GW, as defined in RFC 4861 [32]. Therefore, the PDN GW shall respond with a Neighbor 
Advertisement upon receiving a Neighbor Solicitation message from the UE. 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 77 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

In order to renew the allocated IPv6 prefix, the PDN GW sends a Router Advertisement (solicited or unsolicited) to the 
UE with the same prefix and new non-zero values in preferred and valid lifetime fields. 

In order to release the allocated IPv6 prefix, the PDN GW shall initiate the PDN connection release procedure. Upon 
release of the PDN connection, the UE shall implicitly release the prefix for the corresponding PDN connection. 

NOTE 2: If the PDN type is IPv4v6, when the PDN Connection is released, the IPv4 address is also released. 

After releasing the IPv6 prefix, the PDN GW should not assign that IPv6 prefix to other user immediately. 

5.3.1 .2.3 IPv6 parameter configuration via stateless DHCPv6 

The UE may use stateless DHCPv6 for additional parameter configuration. The PDN GW acts as the DHCP server. 
When PLMN based parameter configuration is used, the PDN GW provides the requested parameters from locally 
provisioned database. When external PDN based parameter configuration is used, the PDN GW obtains the requested 
configuration parameters from the external PDN as described in the previous clauses. When the PDN GW acts as a 
DHCPv6 server towards the UE, the PDN GW may act as DHCPv6 client towards the external PDN to request the 
configuration parameters for the UE. If RADIUS or Diameter is used towards the external PDN as described in 
TS 29.061 [38], the requested configuration parameters can be fetched as part of these procedures. 

5.3.1 .2.4 IPv4 address allocation, renewal and release and IPv4 parameter configuration 
via DHCPv4 

When the PLMN allocates an IPv4 address, it is the PDN GW responsibility to allocate, renew and release the IPv4 
address. 

When external PDN allocation is used, the PDN GW functions as a DHCPv4 server towards the UE. The PDN GW 
may act as a DHCP Client when interacting with a DHCPv4 server in the external PDN in order to obtain, renew and 
release the IPv4 address and to obtain the configuration parameters. Or, if RADIUS or Diameter is used towards the 
external PDN as described in TS 29.061 [38], the IPv4 address and the requested configuration parameters can be 
obtained, renewed and released as part of these procedures. 

If dynamic policy provisioning is deployed, and the PCRF was not informed about the IPv4 address at IP-CAN session 
establishment, the PDN GW shall initiate an IP-CAN Session Modification procedure to inform the PCRF about an 
allocated IPv4 address. If the IPv4 address is released, the PDN GW shall inform the PCRF about the de-allocation of 
an IPv4 address. 

If the UE sends DHCPv4 lease renewal message to renew the lease of the allocated IPv4 address, the PDN GW shall 
renew the lease of the allocated IPv4 address. If the IPv4 address was obtained from an external PDN, the PDN GW 
shall perform the DHCPv4 lease renewal procedure with the external PDN if DHCPv4 was used for obtaining IPv4 
address from external PDN. If Diameter or RADIUS procedures where used to obtain the IPv4 address from external 
PDN, the PDN GW may perform corresponding update procedures as applicable. If the external PDN extends lease of 
the allocated IPv4 address, the PDN GW responds accordingly to the UE. Otherwise, if the external PDN does not 
extend the lease of the allocated IPv4 address, the PDN GW responds with the remaining lease time of the IPv4 address. 
If there is no PDN address allocated to the UE for this PDN connection, the PDN GW shall perform PDN GW initiated 
bearer deactivation procedure as defined in clause 5.4.4.1. 

If the UE sends DHCPv4 release message to release the allocated IPv4 address for the PDN connection, the PDN GW 
may anytime thereafter release the IPv4 address. If the PDN connection has no allocated PDN address, the PDN GW 
may at any time initiate PDN GW initiated bearer deactivation procedure as defined in clause 5.4.4.1. 

NOTE: If the PDN type is IPv4v6 the release of the allocated IPv4 address does not mean that there is no 

allocated PDN address for the PDN connection, as the IPv6 prefix still remains allocated to that PDN 
connection. 

If the PDN connection is released without any DHCPv4 release signalling with the UE, the UE and the PDN GW shall 
release the IPv4 address implicitly, as soon as the PDN connection is released. 

After releasing the IPv4 address, the PDN GW should not assign that IPv4 address to any other user immediately. 

5.3.1.2.5 Void 
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5.3.1 .2.6 IPv6 Prefix Delegation via DHCPv6 

Optionally a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection. In this case, 
the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining 
address space from the network prefix can be delegated to the PDN connection using prefix delegation after the default 
bearer establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in 
clause 5.3.1.2.2. When PLMN based parameter configuration is used, the PDN GW provides the requested IPv6 prefix 
from a locally provisioned pool. When external PDN based IPv6 prefix allocation is used, the PDN GW obtains the 
prefix from the external PDN. 

NOTE: Allocation of IPv6 prefixes with flexible prefix length can leverage e.g. local configuration on the 
PDN GW or interaction with the AAA server. 

The address space provided is maintained as an IPv6 address space pool available to the PDN connection for DHCPv6 
IPv6 prefix requests with the exclusion of the IPv6 prefix that is allocated to the PDN connection during default bearer 
establishment as defined in clause 5.3.1.2.2. The total IPv6 address space available for the PDN connection (UE default 
bearer prefix and UE PDN connection IPv6 address space pool) shall be possible to aggregate into one IPv6 prefix that 
will represent all IPv6 addresses that the UE may use. If the UE had indicated that it supports prefix exclusion and the 
prefix to be delegated to the UE includes the /64 prefix that was allocated to the PDN Connection, the PDN GW shall 
utilise the prefix exclusion feature as specified for DHCPv6 Prefix Delegation in draft-ietf-dhc-pd-exclude-00 [70]. 

The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the PDN 
GW after completing stateless IPv6 address autoconfiguration procedures. The UE acts as a "Requesting Router" as 
described in RFC 3633 [21] and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the UE 
to the PDN GW. The PDN GW acts as the DHCP server and fulfils the role of a "Delegating Router" according to 
RFC 3633 [21]. The UE optionally includes the RAPID_COMMIT option in the DHCPv6 SoHcit message to trigger 
two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE shall include 
OPTION_PD_EXCLUDE option code in an OPTION_ORO option to indicate support for prefix exclusion. In response 
to the DHCPv6 Solicit message, the UE receives a DHCPv6 Reply message with one or more IA_PD prefix(es) for 
every IA_PD option that it sent in the DHCPv6 Solicit message. The PDN GW delegates a prefix excluding the default 
prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow draft-ietf-dhc-pd-exclude- 
00 [70]. 

5.3.2 Attach procedure 
5.3.2.1 E-UTRAN Initial Attach 

A UE/user needs to register with the network to receive services that require registration. This registration is described 
as Network Attachment. The always-on IP connectivity for UE/users of the EPS is enabled by establishing a default 
EPS bearer during Network Attachment. The PCC rules applied to the default EPS bearer may be predefined in the 
PDN GW and activated in the attachment by the PDN GW itself. The Attach procedure may trigger one or multiple 
Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that UE. During the attach 
procedure, the UE may request for an IP address allocation. Terminals utilising only IETF based mechanisms for IP 
address allocation are also supported. 

During the Initial Attach procedure the Mobile Equipment Identity is obtained from the UE. The MME operator may 
check the ME Identity with an EIR. At least in roaming situations, the MME should pass the ME Identity to the HSS, 
and, if a PDN GW outside of the VPLMN, should pass the ME Identity to the PDN GW. 

During the Initial Attach procedure, if the MME supports SRVCC and if any of the conditions described in step 8 in 
Figure5.3.2.1-1 are satisfied, the MME informs the HSS with the UE SRVCC capabiHty e.g. for further IMS 
registration. 

The E-UTRAN Initial Attach procedure is used for Emergency Attach by UEs that need to perform emergency services 
but cannot gain normal services from the network. These UEs are in limited service state as defined in TS 23.122 [10]. 
Also UEs that had attached for normal services and do not have emergency bearers established and are camped on a cell 
in limited service state (e.g. restricted Tracking Area or not allowed CSG) shall initiate the Attach procedures indicating 
that the attach is to receive emergency services. UEs that camp normally on a cell, i.e. UEs that are not in limited 
service state, should initiate normal initial attach when not already attached and shall initiate the UE Requested PDN 
Connectivity procedure to receive emergency EPS bearer services. 
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NOTE 1 : A UE that is emergency attached performs initial attach procedure before being able to obtain normal 
services. 

In order to limit load on the network, only when performing an E-UTRAN Attach with a new PLMN (i.e. not the 
registered PLMN or an equivalent PLMN of the registered PLMN), a UE configured to perform Attach with IMSI at 
PLMN change (see TS 24.368 [69]) shall identify itself by its IMSI instead of any stored temporary identifier. 

This procedure is also used to establish the first PDN connection over E-UTRAN when the UE already has active PDN 
connections over a non-3GPP access network and wants to establish simultaneous PDN connections to different APNs 
over multiple accesses. 
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Figure 5.3.2.1-1: Attach procedure 
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NOTE 2: For a PMIP-based S5/S8, procedure steps (A), (B), and (C) are defined in TS 23.402 [2]. Steps 7, 10, 13, 
14, 15 and 23a/b concern GTP based S5/S8. 

NOTE 3: The Serving GWs and PDN GWs involved in steps 7 and/or 10 may be different to those in steps 13-15. 

NOTE 4: The steps in (D) are executed only upon handover from non-3GPP access. 

NOTE 5: More detail on procedure steps (E) is defined in the procedure steps (B) in clause 5.3.8.3. 

NOTE 6: More detail on procedure steps (F) is defined in the procedure steps (B) in clause 5.3.8.4. 

1. The UE initiates the Attach procedure by the transmission, to the eNodeB, of an Attach Request (IMSI or old 
GUTl, Old GUTl type, last visited TAl (if available), UE Core Network Capability, UE Specific DRX 
parameters. Attach Type, ESM message container (Request Type, PDN Type, Protocol Configuration Options, 
Ciphered Options Transfer Flag), KSIasme, NAS sequence number, NAS-MAC, additional GUTl, P-TMSI 
signature. Voice domain preference and UE's usage setting, MS Network Capability) message together with 
RRC parameters indicating the Selected Network and the old GUMMEl. If the UE identifies itself with the old 
GUTl, the UE shall set the Old GUTl Type to indicate whether the Old GUTl is a native GUTl or is mapped 
from a P-TMSl and RAl. The old GUTl may be derived from a P-TMSl and RAl. IMSl shall be included if the 
UE does not have a valid GUTl or a valid P-TMSl available, or if the UE is configured to perform Attach with 
IMSl at PLMN change and is accessing a new PLMN. The UE stores the TIN in detached state. If the UE's TIN 
indicates "GUTl" or "RAT-related TMSl" and the UE holds a valid GUTl then the old GUTl indicates this valid 
GUTl. If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAl then these two 
elements are indicated as the old GUTl. Mapping a P-TMSl and RAl to a GUTl is specified in TS 23.003 [9]. If 
the UE holds a valid GUTl and the old GUTl indicates a GUTl mapped from a P-TMSI and RAl, then the UE 
indicates the GUTl as additional GUTL If the old GUTl indicates a GUTl mapped from a P-TMSI and RAl and 
the UE has a valid P-TMSl signature associated to it, the P-TMSI signature shall be included. The UE sets the 
voice domain preference and UE's usage setting according to its configuration, as described in clause 4.3.5.9. 

If available, the last visited TAI shall be included in order to help the MME produce a good list of TAIs for any 
subsequent Attach Accept message. Selected Network indicates the PLMN that is selected for network sharing 
purposes. The RRC parameter "old GUMMEl" takes its value from the "old GUTl" contained in the Attach 
Request. UE Network Capability is described in UE capabilities, see clause 5.11. 

If the UE has valid security parameters, the Attach Request message shall be integrity protected by the NAS- 
MAC in order to allow validation of the UE by the MME. KSIasme, NAS sequence number and NAS-MAC are 
included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number of 
the NAS message. If the UE does not have a valid EPS security association, then the Attach Request message is 
not integrity protected. In this case the security association is established in step 5a. The UE network capabilities 
indicate also the supported NAS and AS security algorithms. PDN type indicates the requested IP version (IPv4, 
IPv4/IPv6, IPv6). Protocol Configuration Options (PCO) are used to transfer parameters between the UE and the 
PDN GW, and are sent transparently through the MME and the Serving GW. The Protocol Configuration 
Options may include the Address Allocation Preference indicating that the UE prefers to obtain an IPv4 address 
only after the default bearer activation by means of DHCPv4. If the UE intends to send PCO which require 
ciphering (e.g., PAP/CHAP usernames and passwords) or send an APN, or both, the UE shall set the Ciphered 
Options Transfer Flag and send PCO or APN or both only after authentication and NAS security setup have been 
completed (see below). If the UE has UTRAN or GERAN capabilities, it shall send the NRSU in the PCO to 
indicate the support of the network requested bearer control in UTRAN/GERAN. Request Type is included in 
the ESM message container and indicates "Handover" when the UE has already an activated PDN GW/HA due 
to mobility with non-3GPP accesses. Attach Type indicates whether it is an EPS attach or a combined EPS/IMSI 
attach or an Emergency Attach. 

For an Emergency Attach the UE shall set both the Attach Type and the Request Type to "Emergency" and the 
IMSI shall be included if the UE does not have a valid GUTl or a valid P-TMSI available. The IMEI shall be 
included when the UE has no IMSI, no valid GUTl and no valid P-TMSl. 

2. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEl and the indicated Selected 
Network. If that MME is not associated with the eNodeB or the old GUMMEl is not available, the eNodeB 
selects an MME as described in clause 4.3.8.3 on "MME selection function". The eNodeB forwards the Attach 
Request message to the new MME contained in a SI -MME control message (Initial UE message) together with 
the Selected Network, CSG access mode, CSG ID, L-GW address, and TAIh-ECGI of the cell from where it 
received the message to the new MME. CSG ID is provided if the UE attaches via a CSG cell or hybrid cell. 
CSG access mode is provided if the UE attaches via a hybrid cell. If the CSG access mode is not provided but 
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the CSG ID is provided, the MME shall consider the cell as a CSG cell. If the eNodeB has a collocated L-GW, it 
includes the L-GW address in the Initial UE message to the MME. 

If the MME is not configured to support Emergency Attach the MME shall reject any Attach Request that 
indicates Attach Type "Emergency". 

3. If the UE identifies itself with GUTI and the MME has changed since detach, the new MME determines the type 
of the old node, i.e. MME or SGSN, as specified in clause 4.3. 19, uses the GUTI received from the UE to derive 
the old MME/SGSN address, and sends an Identification Request (old GUTI, complete Attach Request message) 
to the old MME/SGSN to request the IMSI. If the request is sent to an old MME, the old MME first verifies the 
Attach Request message by NAS MAC and then responds with Identification Response (IMSI, MM Context). If 
the request is sent to an old SGSN, the old SGSN first verifies the Attach Request message by the P-TMSI 
signature and then responds with Identification Response (MM Context). If the UE is not known in the old 
MME/SGSN or if the integrity check or P-TMSI signature check for the Attach Request message fails, the old 
MME/SGSN responds with an appropriate error cause. The MM context contains security related information as 
well as other parameters (including IMSI) as described in clause 5.7.2 (Information Storage for MME). 

The additional GUTI in the Attach Request message allows the new MME to find any already existing UE 
context stored in the new MME when the old GUTI indicates a GUTI mapped from a P-TMSI and RAI. 

For an Emergency Attach if the UE identifies itself with a temporary identity that is not known to the MME the 
MME immediately requests the IMSI from the UE. If the UE identifies itself with IMEI, the IMSI request shall 
be skipped. 

NOTE 7: A SGSN always responds with the UMTS security parameters and the MME may store it for later use. 

4. If the UE is unknown in both the old MME/SGSN and new MME, the new MME sends an Identity Request to 
the UE to request the IMSI. The UE responds with Identity Response (IMSI). 

5a If no UE context for the UE exists anywhere in the network, if the Attach Request (sent in step 1) was not 
integrity protected, or if the check of the integrity failed, then authentication and NAS security setup to activate 
integrity protection and NAS ciphering are mandatory. Otherwise it is optional. If NAS security algorithm is to 
be changed, the NAS security setup is performed in this step. The authentication and NAS security setup 
functions are defined in clause 5.3.10 on "Security Function". 

If the MME is configured to support Emergency Attach for unauthenticated IMSIs and the UE indicated Attach 
Type "Emergency" the MME skips the authentication and security setup or the MME accepts that the 
authentication may fail and continues the attach procedure. 

After step 5a, all NAS messages shall be protected by the NAS security functions (integrity and ciphering) 
indicated by the MME unless the UE is emergency attached and not successfully authenticated. 

5b. The ME Identity shall be retrieved from the UE. The ME identity shall be transferred encrypted unless the UE 
performs Emergency Attach and cannot be authenticated. 

For an Emergency Attach, the UE may have included the IMEI in the Emergency Attach. If so, the ME Identity 
retrieval is skipped. 

In order to minimise signalling delays, the retrieval of the ME Identity may be combined with NAS security 
setup in step 5a. The MME may send the ME Identity Check Request (ME Identity, IMSI) to the EIR. The EIR 
shall respond with ME Identity Check Ack (Result). Dependent upon the Result, the MME decides whether to 
continue with this Attach procedure or to reject the UE. 

For an Emergency Attach, the IMEI check to the EIR may be performed. If the IMEI is blocked, operator 
policies determine whether the Emergency Attach procedure continues or is stopped. 

6. If the UE has set the Ciphered Options Transfer Flag in the Attach Request message, the Ciphered Options i.e. 
PCO or APN or both, shall now be retrieved from the UE. 

In order to handle situations where the UE may have subscriptions to multiple PDNs, if the Protocol 
Configuration Options contains user credentials (e.g. user name/password within PAP or CHAP parameters) then 
the UE should also send the APN to the MME. 

7. If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-attaches to the same 
MME without having properly detached before), the new MME deletes these bearer contexts by sending Delete 
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Session Request (LB I) messages to the GWs involved. The GWs acknowledge with Delete Session Response 
(Cause) message. If a PCRF is deployed, the PDN GW employs an IP-CAN Session Termination procedure to 
indicate that resources have been released. 

8. If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME, 
or if the UE provides an IMSI or the UE provides an old GUTI which doesn't refer to a valid context in the 
MME, the MME sends an Update Location Request (MME Identity, IMSI, ME Identity, MME CapabiUties, 
ULR-Flags, Homogeneous Support of IMS Over PS Sessions, UE SRVCC capability) message to the HSS. The 
MME capabilities indicate the MME's support for regional access restrictions functionality. ULR-Flags indicates 
"Initial-Attach-Indicator" as this is an Attach procedure. Homogenous Support of IMS Over PS Sessions 
indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all TAs in the serving 
MME. 

If the MME determines that only the UE SRVCC capability has changed, the MME sends a Notify Request to 
the HSS to inform about the changed UE SRVCC capability. 

For an Emergency Attach in which the UE was not successfully authenticated, the MME shall not send an 
Update Location Request to the HSS. 

9. The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The old MME acknowledges with 
Cancel Location Ack (IMSI) and removes the MM and bearer contexts. If the ULR-Flags indicates "Initial- 
Attach-Indicator" and the HSS has the SGSN registration, then the HSS sends Cancel Location (IMSI, 
Cancellation Type) to the old SGSN. The Cancellation Type indicates the old MME/SGSN to release the old 
Serving GW resource. 

10. If there are active bearer contexts in the old MME/SGSN for this particular UE, the old MME/SGSN deletes 
these bearer contexts by sending Delete Session Request (LBI) messages to the GWs involved. The GWs return 
Delete Session Response (Cause) message to the old MME/SGSN. If a PCRF is deployed, the PDN GW 
employs an IP-CAN Session Termination procedure as defined in TS 23.203 [6] to indicate that resources have 
been released. 

11. The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription 
data) message to the new MME. The Subscription Data contain one or more PDN subscription contexts. Each 
PDN subscription context contains an 'EPS subscribed QoS profile' and the subscribed APN-AMBR (see 
clause 4.7.3). The new MME validates the UE's presence in the (new) TA. If due to regional subscription 
restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to attach in the TA or due to 
subscription checking fails for other reasons, the new MME rejects the Attach Request with an appropriate 
cause. If all checks are successful then the new MME constructs a context for the UE. If the APN provided by 
the UE is not allowed by subscription, or the Update Location is rejected by the HSS, the new MME rejects the 
Attach Request from the UE with an appropriate cause. 

The Subscription Data may contain CSG subscription information. If the UE provided APN is authorized for 
LIPA according to the user subscription, the MME shall use the CSG Subscription Data to authorize the 
connection. 

For an Emergency Attach the MME shall not check for access restrictions, regional restrictions or subscription 
restrictions (e.g. CSG restrictions). For an Emergency Attach, the MME shall ignore any unsuccessful Update 
Location Response from HSS and continue with the Attach procedure. 

12. For an Emergency Attach the MME applies the parameters from MME Emergency Configuration Data for the 
emergency bearer establishment performed in this step and any potentially stored IMSI related subscription data 
are ignored by the MME. 

If the UE performs Initial or Handover Attach via a CSG cell and there is no subscription for that CSG or the 
CSG subscription is expired the MME shall reject the Attach Request with an appropriate cause. If the UE has 
this CSG ID on its Allowed CSG list the UE shall remove the CSG ID from the list when receiving this reject 
cause. 

If a subscribed PDN address is allocated for the UE for this APN, the PDN subscription context contains the 
UE's IPv4 address and/or the IPv6 prefix and optionally the PDN GW identity. If the PDN subscription context 
contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. For Request 
Type indicating "Initial request", if the UE does not provide an APN, the MME shall use the PDN GW 
corresponding to the default APN for default bearer activation. If the UE provides an APN, this APN shall be 
employed for default bearer activation. For Request Type indicating "Handover", if the UE provides an APN, the 
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MME shall use the PDN GW corresponding to the provided APN for default bearer activation, If the UE does 
not provide an APN, and the subscription context from HSS contains a PDN GW identity corresponding to the 
default APN, the MME shall use the PDN GW corresponding to the default APN for default bearer activation. 
The case where the Request Type indicates "Handover" and the UE does not provide an APN, and the 
subscription context from HSS does not contain a PDN GW identity corresponding to the default APN 
constitutes an error case. If the Request Type indicates "Initial request" and the selected PDN subscription 
context contains no PDN GW identity the new MME selects a PDN GW as described in clause 4.3.8.1 on PDN 
GW selection function (3GPP accesses). If the PDN subscription context contains a dynamically allocated PDN 
GW identity and the Request Type does not indicate "Handover" the MME may select a new PDN GW as 
described in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for more efficient 
routing. 

For initial and handover Emergency Attach the MME uses the PDN GW Selection function defined in Section 
4.3.12.4 to select a PDN GW. 

The new MME selects a Serving GW as described in clause 4.3.8.2 on Serving GW selection function and 
allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create Session 
Request (IMSI, MSISDN, MME TEID for control plane, PDN GW address, PDN Address, APN, RAT type. 
Default EPS Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, 
Handover Indication, ME Identity, User Location Information (ECGI), UE Time Zone, User CSG Information, 
MS Info Change Reporting support indication. Selection Mode, Charging Characteristics, Trace Reference, 
Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the Protocol 
Type over S5/S8, Serving Network) message to the selected Serving GW. User CSG Information includes CSG 
ID, access mode and CSG membership indication. 

If the Request Type indicates "Emergency", Maximum APN restriction control shall not be performed. 

For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated then the IMSI 
shall be marked as unauthenticated. 

The RAT type is provided in this message for the later PCC decision. The subscribed APN-AMBR for the APN 
is also provided in this message. The MSISDN is included if provided in the subscription data from the HSS. 
Handover Indication is included if the Request Type indicates handover. Selection Mode indicates whether a 
subscribed APN was selected, or a non-subscribed APN sent by the UE was selected. Charging Characteristics 
indicates which kind of charging the bearer context is liable for. The MME may change the requested PDN type 
according to the subscription data for this APN as described in clause 5.3.1.1. The MME shall set the Dual 
Address Bearer Flag when the PDN type is set to IPv4v6 and all SGSNs which the UE may be handed over to 
are Release 8 or above supporting dual addressing, which is determined based on node pre-configuration by the 
operator. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 
interface. 

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of 
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [44]. 
The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace 
is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information 
received from the HLR or OMC. 

The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer 
context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 
of TS 23.060 [7]). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the 
Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer 
context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with 
sending an appropriate error cause to the UE. 

13. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, 
MSISDN, APN, Serving GW Address for the user plane. Serving GW TEID of the user plane. Serving GW 
TEID of the control plane, RAT type. Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN- 
AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location 
Information (ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication. 
Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum 
APN Restriction, Dual Address Bearer Flag, Serving Network) message to the PDN GW indicated by the PDN 
GW address received in the previous step. After this step, the Serving GW buffers any downlink packets it may 
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receive from the PDN GW without sending a Downlink Data Notification message to the MME until it receives 
the Modify Bearer Request message in step 23 below. The MSISDN is included if received from the MME. 

If the Request Type indicates "Emergency", Maximum APN restriction control shall not be performed. 

For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated then the IMSI 
shall be marked as unauthenticated. 

14. If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW performs an IP-CAN 
Session Establishment procedure as defined in TS 23.203 [6], and thereby obtains the default PCC rules for the 
UE. This may lead to the establishment of a number of dedicated bearers following the procedures defined in 
clause 5.4.1 in association with the establishment of the default bearer, which is described in Annex F. 

The IMSI, APN, UE IP address. User Location Information (ECGI), UE Time Zone, Serving Network, RAT 
type, APN-AMBR, Default EPS Bearer QoS are provided to the PCRF by the PDN GW if received by the 
previous message. The User Location Information and UE Time Zone are used for location based charging. For 
emergency attached UEs which are unauthenticated the PDN GW provides the IMEI as the UE Identity instead 
of IMSI, to the PCRF. 

The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP) associated with the default 
bearer in the response to the PDN GW as defined in TS 23.203 [6]. 

If the PCC is configured to support emergency services and if dynamic PCC is deployed, the PCRF, based on the 
emergency APN, sets the ARP of the PCC rules to a value that is reserved for emergency services and the 
authorization of dynamic PCC rules as described in of TS 23.203 [6]. If dynamic PCC is not deployed, the PDN 
GW uses the ARP of the default emergency EPS bearer for any potentially initiated dedicated emergency EPS 
bearer. The P-GW determines that emergency services are requested based on the emergency APN received in 
Create Session Request message. 

NOTE 8: While the PDN GW/PCEF may be configured to activate predefined PCC rules for the default bearer, the 
interaction with the PCRF is still required to provide e.g. the UE IP address information to the PCRF. 

NOTE 9: If the IP address is not available when the PDN GW performs the IP-CAN Session Establishment 

procedure with the PCRF, the PDN GW initiates an IP -CAN Session Modification procedure to inform 
the PCRF about an allocated IP address as soon as the address is available. In this version of the 
specification, this is applicable only to IPv4 address allocation. 

If dynamic PCC is deployed and the Handover Indication is present, the PDN GW executes a PCEF Initiated 
IP-CAN Session Modification procedure with the PCRF as specified in TS 23.203 [6] to report the new IP-CAN 
type. Depending on the active PCC rules, the establishment of dedicated bearers for the UE may be required. The 
establishment of those bearers shall take place in combination with the default bearer activation as described in 
Annex F. This procedure can continue without waiting for a PCRF response. If changes to the active PCC rules 
are required, the PCRF may provide them after the handover procedure is finished. 

In both cases (Handover Indication is present or not), if dynamic PCC is not deployed, the PDN GW may apply 
local QoS policy. This may lead to the establishment of a number of dedicated bearers for the UE following the 
procedures defined in clause 5.4.1 in combination with the establishment of the default bearer, which is 
described in Annex F. 

If the CSG information reporting triggers are received from the PCRF, the PDN GW should set the CSG 
Information Reporting Action IE accordingly. 

15. The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows 
the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The 
way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251 [44]. 
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The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the 
user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, EPS Bearer 
QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS 
Info Change Reporting Action (Start) (if the PDN GW decides to receive UE's location information during the 
session), CSG Information Reporting Action (Start) (if the PDN GW decides to receive UE's User CSG 
information during the session), APN-AMBR) message to the Serving GW. The PDN GW takes into account the 
received PDN type, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the 
PDN type to be used as follows. If the received PDN type is IPv4v6 and both IPv4 and IPv6 addressing is 
possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing for this 
APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the received PDN 
type is IPv4 or IPv6, the PDN GW uses the received PDN type if it is supported in the PDN, otherwise an 
appropriate error cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN 
type. If the PDN GW has selected a PDN type different from the received PDN Type, the PDN GW indicates 
together with the PDN type IE a reason cause to the UE why the PDN type has been modified, as described in 
clause 5.3.1.1. PDN Address may contain an IPv4 address for IPv4 and/or an IPv6 prefix and an Interface 
Identifier. If the PDN has been configured by the operator so that the PDN addresses for the requested APN shall 
be allocated by usage of DHCPv4 only, or if the PDN GW allows the UE to use DHCPv4 for address allocation 
according to the Address Allocation Preference received from the UE, the PDN Address shall be set to 0.0.0.0, 
indicating that the IPv4 PDN address shall be negotiated by the UE with DHCPv4 after completion of the 
Default Bearer Activation procedure. For external PDN addressing for IPv6, the PDN GW obtains the IPv6 
prefix from the external PDN using either RADIUS or Diameter client function. In the PDN Address field of the 
Create Session Response, the PDN GW includes the Interface Identifier and IPv6 prefix. The PDN GW sends 
Router Advertisement to the UE after default bearer establishment with the IPv6 prefix information for all cases. 

If the PDN address is contained in the Create Session Request, the PDN GW shall allocate the IPv4 address 
and/or IPv6 prefix contained in the PDN address to the UE. The IP address allocation details are described in 
clause 5.3.1 on "IP Address Allocation". The PDN GW derives the BCM based on the NRSU and operator 
policy. Protocol Configuration Options contains the BCM as well as optional PDN parameters that the P-GW 
may transfer to the UE. These optional PDN parameters may be requested by the UE, or may be sent unsolicited 
by the P-GW. Protocol Configuration Options are sent transparently through the MME. 

When the Handover Indication is present, the PDN GW does not yet send downlink packets to the S-GW; the 
downlink path is to be switched at step 23a. 

If the PDN GW is an L-GW, it does not forward downlink packets to the S-GW. The packets will only be 
forwarded to the HeNB at step 20 via the direct user plane path. 

16. If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are 
received for this bearer context, then the S-GW shall store this for the bearer context and the S-GW shall report 
to that P-GW whenever a UE's location and/or User CSG information change occurs that meets the P-GW 
request, as described in clause 15.1.1a of TS 23.060 [7]. 

The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User 
Plane, Serving GW TEID for Sl-U User Plane, Serving GW TEID for control plane, EPS Bearer Identity, EPS 
Bearer QoS, PDN GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN 
GW(s) for uplink traffic. Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, 
Cause, MS Info Change Reporting Action (Start), CSG Information Reporting Action (Start), APN-AMBR) 
message to the new MME. 

17. If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall 
check this received value with the stored value for the Maximum APN Restriction to ensure there are no 
conflicts between values. If the Bearer Context is accepted, the MME shall determine a (new) value for the 
Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the 
Maximum APN Restriction shall be set to the value of the received APN Restriction. MME shall not deactivate 
bearer(s) with emergency ARP, if present, to maintain valid APN restriction combination. 

The P-GW shall ignore Maximum APN restriction if the request includes the Emergency APN. 

If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are 
received for this bearer context, then the MME shall store this for the bearer context and the MME shall report 
whenever a UE's location and/or User CSG information change occurs that meets the request, as described in 
clause 15.1.1a of TS 23.060 [7]. 
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The MME determines the UE AMBR to be used by the eNodeB based on the subscribed UE-AMBR and the 
APN-AMBR for the default APN, see clause 4.7.3. 

For emergency attach the MME determines the UE-AMBR to be used by the eNodeB from the APN AMBR 
received from the S-GW. 

The new MME sends an Attach Accept (APN, GUTI, PDN Type, PDN Address, TAI List, EPS Bearer Identity, 
Session Management Request, Protocol Configuration Options, NAS sequence number, NAS-MAC, IMS Voice 
over PS session supported Indication, Emergency Service Support indicator, LCS Support Indication) message to 
the eNodeB. GUTI is included if the new MME allocates a new GUTI. This message is contained in an 
S1_MME control message Initial Context Setup Request. This SI control message also includes the AS security 
context information for the UE, the Handover Restriction List, the EPS Bearer QoS, the UE-AMBR, EPS Bearer 
Identity, as well as the TEID at the Serving GW used for user plane and the address of the Serving GW for user 
plane. In addition, if the PDN connection is established for Local IP Access, the SI control message includes a 
Correlation ID for enabling the direct user plane path between the HeNB and the L-GW. 

NOTE 10: In this release of the 3GPP specification the Correlation ID is set equal to the user plane PDN GW TEID 
(GTP -based S5) or GRE key (PMIP-based S5) that the MME has received in step 16. 

In the Attach Accept message, the MME does not include the IPv6 prefix within the PDN Address. The MME 
includes the EPS Bearer QoS parameter QCI and APN-AMBR into the Session Management Request. 
Furthermore, if the UE has UTRAN or GERAN capabilities and the network supports mobility to UTRAN or 
GERAN, the MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters 
QoS Negotiated (R99 QoS profile). Radio Priority, Packet Flow Id and TI and includes them in the Session 
Management Request. If the UE indicated in the UE Network Capability it does not support BSS packet flow 
procedures, then the MME shall not include the Packet Flow Id. Handover Restriction List is described in clause 
4.3.5.7 "Mobility Restrictions". The MME sets the IMS Voice over PS session supported Indication as described 
in clause 4.3.5.8. LCS Support Indication indicates whether the network supports the EPC-MO-LR and/or CS- 
MO-LR as described in TS 23.271 [57]. 

If the UE initiates the Attach procedure at a hybrid cell, the MME shall check whether the CSG ID is contained 
in the CSG subscription and is not expired. The MME shall send an indication whether the UE is a CSG member 
to the RAN along with the SI -MME control message. Based on this information the RAN may perform 
differentiated treatment for CSG and non-CSG members. 

If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as 
described in clause 5.3.1.1. 

For an emergency attached UE, i.e. for UEs that have only emergency EPS bearers established, there is no AS 
security context information included in the S 1 control messages and there is no NAS level security when the 
UE cannot be authenticated. The Emergency Service Support indicator informs the UE that Emergency bearer 
services are supported, i.e. the UE is allowed to request PDN connectivity for emergency services. 

18. The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to 
the UE, and the Attach Accept message will be sent along to the UE. The UE shall store the QoS Negotiated, 
Radio Priority, Packet Flow Id and TI, which it received in the Session Management Request, for use when 
accessing via GERAN or UTRAN. The APN is provided to the UE to notify it of the APN for which the 
activated default bearer is associated. For further details, see TS 36.331 [37]. The UE may provide EPS Bearer 
QoS parameters to the application handling the traffic flow(s). The application usage of the EPS Bearer QoS is 
implementation dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS 
Bearer QoS parameters contained in the Session Management Request. 

If the attach procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving 
the Attach accept shall check if the CSG ID of the cell where the UE has sent the Attach Request message is 
contained in its Allowed CSG list. If the CSG ID is not in the UE's Allowed CSG list, the UE shall add the CSG 
ID to its Allowed CSG list. Manual CSG selection is not supported when an emergency service has been 
initiated. 

NOTE 1 1 : If the UE receives an Attach Accept message via a hybrid cell, the UE does not add the corresponding 

CSG ID to its Allowed CSG Ust. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

When receiving the Attach Accept message the UE shall set its TIN to "GUTI" as no ISR Activated is indicated. 
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If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address with DHCPv4 as specified in 
TS 29.061 [38]. If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from 
the network with the IPv6 prefix information or it may send a Router Solicitation if necessary. 

NOTE 12:The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation". 

19. The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. For further details, see 
TS 36.331 [37]. 

20. The eNodeB sends the Initial Context Response message to the new MME. This Initial Context Response 
message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U 
reference point. If the Correlation ID was included in the Initial Context Setup Request message, the eNodeB 
shall use the included information to establish direct user plane path with the L-GW and forward uplink data for 
Local IP Access accordingly. 

21. The UE sends a Direct Transfer message to the eNodeB, which includes the Attach Complete (EPS Bearer 
Identity, NAS sequence number, NAS-MAC) message. 

22. The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS Transport message. 

After the Attach Accept message and once the UE has obtained a PDN Address, the UE can then send uplink 
packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN GW. If the UE requested 
for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) 
by the network with a reason cause indicating that only single IP version per PDN connection is allowed sent 
together with the PDN type, the UE should request for the activation of a parallel PDN connection to the same 
APN with a single address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no 
reason cause in step 18 in response to an IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from 
the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDN was 
successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may 
send Router Solicitation if necessary. 

23. Upon reception of both, the Initial Context Response message in step 21 and the Attach Complete message in 
step 22, the new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, 
Handover Indication) message to the Serving GW. 

23a. If the Handover Indication is included in step 23, the Serving GW sends a Modify Bearer Request (Handover 
Indication) message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to 
3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated 
EPS bearers established. 

23b. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW. 

24. The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) message to the new 
MME. The Serving GW can then send its buffered downlink packets. 

25. After the MME receives Modify Bearer Response (EPS Bearer Identity) message, if Request Type does not 
indicate handover and an EPS bearer was established and the subscription data indicates that the user is allowed 
to perform handover to non-3GPP accesses, and if the MME selected a PDN GW that is different from the PDN 
GW identity which was indicated by the HSS in the PDN subscription context, the MME shall send a Notify 
Request including the APN and PDN GW identity to the HSS for mobility with non-3GPP accesses. The 
message shall include information that identifies the PLMN in which the PDN GW is located. 

If the ME identity of the UE has changed and step 8 has not been performed, the MME sends a Notify Request 
(ME Identity) message to inform the HSS of the updated ME identity. 

For an Emergency Attach the MME shall not send any Notify Request to an HSS. 

26. The HSS stores the APN and PDN GW identity pair and sends a Notify Response to the MME. 

NOTE 13: For handover from non-3GPP access, the PDN GW initiates resource allocation deactivation procedure in 
the trusted/untrusted non-3GPP IP access as specified in TS 23.402 [2]. 
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5.3.2.2 UTRAN/GERAN Initial Attach 

When a UE attaches to UTRAN/GERAN, it executes the normal attach procedure as defined in TS 23.060 [7]. When 
the UE needs an IP address, it initiates PDP context activation procedure as defined in TS 23.060 [7]. 

This procedure along with PDP context activation is also used to establish the first PDN connection over 
UTRAN/GERAN when the UE already has active PDN connections over a non-3GPP access network and wants to 
establish simultaneous PDN connections to different APNs over multiple accesses. 

5.3.3 Tracking Area Update procedures 
5.3.3.0 Triggers for tracking area update 

A standalone tracking area update (with or without S-GW change, described in clauses 5.3.3.1 and 5.3.3.2 respectively) 
occurs when a GPRS-attached or E-UTRAN-attached UE experiences any of the following conditions: 

UE detects it has entered a new TA that is not in the list of TAIs that the UE registered with the network (except 
for the case of a UE configured to perform Attach with IMS I when entering a TA in a new non-equivalent 
PLMN in RRC-IDLE mode); 

the periodic TA update timer has expired; 

- UE was in UTRAN PMM_Connected state (e.g. URA_PCH) when it reselects to E-UTRAN; 

- UE was in GPRS READY state when it reselects to E-UTRAN; 

the TIN indicates "P-TMSI" when the UE reselects to E-UTRAN (e.g. due to bearer configuration modifications 
performed on GERAN/UTRAN); 

the RRC connection was released with release cause "load re-balancing TAU required"; 

the RRC layer in the UE informs the UE's NAS layer that an RRC connection failure (in either E-UTRAN or 
UTRAN) has occurred; 

a change of the UE Network Capability and/or MS Network Capability and/or UE Specific DRX Parameters 
and/or TS 24.008 [47] MS Radio Access capability (e.g. due to GERAN radio capability change or CDMA 2000 
Radio Access Technology Capability change) information of the UE. 

for a UE supporting CS fallback, or configured to support IMS voice, or both, a change of the UE's usage setting 
or voice domain preference for E-UTRAN. 

for a SR-VCC capable UE, a change of MS Classmark 2 and/or MS Classmark 3 and/or Supported Codecs. 

UE manually selects a CSG cell whose CSG ID is absent from both the UE's Allowed CSG list and the UE's 
Operator CSG list. 

NOTE 1: The complete hst of TAU triggers is specified in TS 24.301 [46]. 

The procedure is initiated by an UE in either ECM-IDLE state or ECM-CONNECTED state. The decision to perform 
S-GW change during the tracking area update procedure is made by the MME independently from the triggers above. 

If SIPTO is enabled for a PDN connection, the MME should re-evaluate whether the PGW location is still acceptable. If 
the MME determines that PGW re-location is needed, the MME may initiate PDN deactivation with reactivation 
requested according to clause 5.10.3 at the end of the tracking area/routing area update procedure. 

NOTE 2. It depends on the operator's configuration in the MME whether to use the deactivation with reactivation 
request or allow the continued usage of the already connected GW. 

If LIPA is active for a PDN connection of the UE, the source MME (or S4-SGSN) shall not include LIPA bearer(s) in 
the EPS bearer Context during Tracking Area Update procedure and shall release the core network resources of this 
LIPA PDN connection by peforming the MME requested PDN disconnection procedure according to steps 2 to 6 of 
clause 5.10.3 before it responds with the Context Response message in the case of inter-MME/SGSN mobility or after it 
receives Tracking Area Update Request in the case of intra-MME mobility. 
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NOTE 3: The source MME may not be able to release the LIPA PDN connection after the Context Response is sent 
as when there is no SGW relocation, the SGW will assign the S 1 1 control tunnel of the UE to the new 
MME after the new MME updates the context information. 

During the Tracking Area Update procedure, if the MME supports SRVCC and if the UE SRVCC capability has 
changed, the MME informs the HSS with the UE SRVCC capability e.g. for further IMS registration. 

The cell selection for UTRAN is described in TS 25.304 [12] and TS 25.331 [33]. 

5.3.3.0A Provision of UE's TAI to MME in ECM-CONNECTED state 

The eNodeB shall include the TAI+ECGI of the current cell in every Sl-AP UPLINK NAS TRANSPORT message. 

NOTE: An eNodeB can contain cells from more than one Tracking Area and intra-eNodeB cell changes are not 
normally notified to the MME. However, the MME needs to know the UE's current TAI in order to 
correctly produce a TAU accept message. 



5.3.3.1 
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Figure 5.3.3.1-1 : Tracking Area Update procedure with Serving GW change 

NOTE 1: For a PMIP -based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 9 and 10 
concern GTP based S5/S8. 

NOTE 2: In case of Tracking Area Update without MME change the signalling in steps 4, 5, 7 and steps 12-17 are 
skipped. 

1 . One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs. 
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2. The UE initiates the TAU procedure by sending, to the eNodeB, a TAU Request (UE Core Network Capability, 
MS Network CapabiUty, old GUTI, Old GUTI type, last visited TAI, active flag, EPS bearer status, P-TMSI 
Signature, additional GUTI, eKSI, NAS sequence number, NAS-MAC, KSI, Voice domain preference and UE's 
usage setting) message together with RRC parameters indicating the Selected Network and the old GUMMEI. 
An exception is that, if the TAU was triggered for load re-balancing purposes (see clause 4.3.7.3), the old 
GUMMEI is not included in the RRC parameters. The UE shall set the Old GUTI Type to indicate whether the 
Old GUTI is a native GUTI or is mapped from a P-TMSI and RAI. 

If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI 
indicates this valid GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAI 
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in 
Annex H. When the UE is in connected mode (e.g. in URA_PCH) when it reselects to E-UTRAN, the UE shall 
set its TIN to "P-TMSI". 

If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE 
indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and 
the UE has a valid P-TMSI signature, the P-TMSI signature shall be included. 

The additional GUTI in the Tracking Area Update Request message allows the new MME to find any already 
existing UE context stored in the new MME when the old GUTI indicates a value mapped from a P-TMSI and 
RAI. 

The RRC parameter "old GUMMEI" takes its value from the identifier that is signalled as the old GUTI 
according to the rules above. For a combined MME/SGSN the eNodeB is configured to route the MME-code(s) 
of this combined node to the same combined node. This eNodeB is also configured to route MME-code(s) of 
GUTIs that are generated by the UE's mapping of the P-TMSIs allocated by the combined node. Such an 
eNodeB configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter 
RAT mobility. 

The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent 
TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by UE to 
activate the radio and S 1 bearers for all the active EPS Bearers by the TAU procedure when the UE is in ECM- 
IDLE state. The EPS bearer status indicates each EPS bearer that is active in the UE. The TAU Request message 
shall be integrity protected by the NAS-MAC as described in TS 33.401 [41]. eKSI, NAS sequence number and 
NAS-MAC are included if the UE has valid EPS security parameters. NAS sequence number indicates the 
sequential number of the NAS message. KSI is included if the UE indicates a GUTI mapped from a P-TMSI in 
the information element "old GUTI". 

The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in 
clause 4.3.5.9. 

3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected 
Network. If that MME is not associated with that eNodeB or the GUMMEI is not available or the UE indicates 
that the TAU procedure was triggered by load re-balancing, the eNodeB selects an MME as described in clause 
4.3.8.3 on "MME Selection Function". 

The eNodeB forwards the TAU Request message together with the CSG access mode, CSG ID, TAIh-ECGI of 
the cell from where it received the message and with the Selected Network to the new MME. CSG ID is 
provided by RAN if the UE sends the TAU Request message via a CSG cell or a hybrid cell. CSG access mode 
is provided if the UE sends the TAU Request message via a hybrid cell. If the CSG access mode is not provided 
but the CSG ID is provided, the MME shall consider the cell as a CSG cell. 

4. The new MME differentiates the type of the old node, i.e. MME or SGSN, as specified in clause 4.3. 19, uses the 
GUTI received from the UE to derive the old MME/S4 SGSN address, and sends a Context Request (old GUTI, 
complete TAU Request message, P-TMSI Signature, MME Address, UE validated) message to the old MME/old 
S4 SGSN to retrieve user information. UE Validated indicates that the new MME has validated the integrity 
protection of the TAU message, e.g. based on native EPS security context for the UE. To validate the Context 
Request the old MME uses the complete TAU Request message and the old S4 SGSN uses the P-TMSI 
Signature and responds with an appropriate error if integrity check fails in old MME/S4 SGSN. This shall 
initiate the security functions in the new MME. If the security functions authenticate the UE correctly, the new 
MME shall send a Context Request (IMSI, complete TAU Request message, MME Address, UE Vahdated) 
message to the old MME/S4 SGSN with the UE Validated set. If the new MME indicates that it has 
authenticated the UE or if the old MME/old S4 SGSN correctly vaUdates the UE, then the old MME/old 

S4 SGSN starts a timer. 
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If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting 
unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and 
starting the timer also when it cannot validate the Context Request. 

5. If the Context Request is sent to an old MME the old MME responds with a Context Response (IMSI, ME 
Identity (if available), MSISDN, MM Context, EPS Bearer Context(s), Serving GW signalling Address and 
TEID(s), ISR Supported, MS Info Change Reporting Action (if available), CSG Information Reporting Action 
(if available), UE Time Zone, UE Core Network Capability, UE Specific DRX Parameters) message. 

If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response (MM 
Context, EPS Bearer Context(s), Serving GW signalling Address and TEID(s), ISR Supported, MS Info Change 
Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, UE Core 
Network Capability, UE Specific DRX Parameters). 

The MM Context contains security related information as well as other parameters (including IMSI, ME Identity 
(if available) and MSISDN) as described in clause 5.7.2 (Information Storage for MME). The unused 
Authentication Quintets in the MM Context are also maintained in the SGSN. TS 33.401 [41] gives further 
details on the transfer of security related information. 

The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at the PDN 
GW(s) for uplink traffic) and the TI(s), is part of the EPS Bearer Context. If the UE is not known in the old 
MME/old S4 SGSN or if the integrity check for the TAU Request message fails, the old MME/old S4 SGSN 
responds with an appropriate error cause. ISR Supported is indicated if the old MME/old S4 SGSN and 
associated Serving GW are capable to activate ISR for the UE. The MSISDN is included if the old MME/old 
S4 SGSN has it stored for that UE. 

If the UE receives emergency services from the old MME/old S4 SGSN and the UE is UlCCless, IMSI can not 
be included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the 
IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available. 

6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. The 
authentication functions are defined in clause 5.3.10 on "Security Function". Ciphering procedures are described 
in clause 5.3.10 on "Security Function". If GUTI allocation is going to be done and the network supports 
ciphering, the NAS messages shall be ciphered. 

If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the 
TAI sent by the eNodeB in Step 3 is different from that of the GUTI,included in the TAU Request message, the 
MME shall delay authenticating the UE until after Step 21 (TAU Complete message). 

NOTE 3: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new 

PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE 
as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is 
used in the derivation of the Kasme key by both the network and the UE. 

If the new MME is configured to allow emergency services for unauthenticated UE the new MME behave as 
follows: 

where a UE has only emergency bearer services, the MME either skip the authentication and security 
procedure or accepts that the authentication may fail and continues the Tracking Area Update procedure; or 

where a UE has both emergency and non emergency bearer services and authentication fails, the MME 
continues the Tracking Area Update procedure and deactivates all the non-emergency PDN connections as 
specified in clause 5.10.3. 

7. The MME (if the MME has changed then it is the new MME) determines to relocate the Serving GW. The 
Serving GW is relocated when the old Serving GW cannot continue to serve the UE. The MME (if the MME has 
changed then it is the new MME) may also decide to relocate the Serving GW if a new Serving GW is expected 
to serve the UE longer and/or with a more optimal UE to PDN GW path, or if a new Serving GW can be co- 
located with the PDN GW. Selection of a new Serving GW is performed according to clause 4.3.8.2 on "Serving 
GW selection function". 

If the MME has changed the new MME sends a Context Acknowledge (Serving GW change indication) message 
to the old MME/old S4 SGSN. Serving GW change indication indicates a new Serving GW has been selected. 
The old MME/old S4 SGSN marks in its UE context that the information in the GWs is invalid. And, if the old 
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node is an MME, the old MME marks in its UE context that the information in the HSS is invalid. This ensures 
that the old MME/old S4 SGSN updates the GWs, and the old MME updates the HSS, if the UE initiates a TAU 
or RAU procedure back to the old MME/old S4 SGSN before completing the ongoing TAU procedure. If the 
security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the new MME shall 
send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the 
Identification and Context Request was never received. 

ISR is not indicated in the Context Acknowledge as ISR is not activated due to the S-GW change. 

8. If the MME has changed the new MME verifies the EPS bearer status received from the UE with the bearer 
contexts received from the old MME/old S4 SGSN. If the MME has not changed the MME verifies EPS bearer 
status from the UE with the bearer contexts available in the MM context. The MME releases any network 
resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects 
the TAU Request. 

If the MME selected a new Serving GW it sends a Create Session Request (IMSI, bearer contexts, MME 
Address and TEID, Type, the Protocol Type over S5/S8, RAT type. Serving Network, UE Time Zone) message 
per PDN connection to the selected new Serving GW. The PDN GW address and TFT (for PMIP-based S5/S8) 
are indicated in the bearer Contexts. Type indicates to the Serving GW to send the Modify Bearer Request to the 
PDN GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 
interface. RAT type indicates a change in radio access. If the PDN GW requested UE's location and/or User CSG 
information, the MME also includes the User Location Information IE and/or User CSG Information IE in this 
message. 

NOTE 4: The User CSG Information IE is only sent in step 8 if the "Active flag" is set in the TAU Request 

message. 

9. The Serving GW informs the PDN GW(s) about the change of for example the RAT type that e.g. can be used 
for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type. 
Serving Network) per PDN connection to the PDN GW(s) concerned. User Location Information IE and/or UE 
Time Zone IE and/or User CSG Information IE are also included if they are present in step 8. 

9a If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF, 
then the PDN GW shall send RAT type information to the PCRF by means of an IP-CAN Session Modification 
procedure as defined in TS 23.203 [6]. 

NOTE 5: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

10. The PDN GW updates its bearer contexts and returns a Modify Bearer Response (MSISDN, Charging Id) 
message. The MSISDN is included if the PDN GW has it stored in its UE context. 

1 1 . The Serving GW updates its bearer context. This allows the Serving GW to route bearer PDUs to the PDN GW 
when received from eNodeB. 

The Serving GW returns a Create Session Response (Serving GW address and TEID for user plane and control 
plane and PDN GW TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) for uplink traffic and 
control plane) message to the new MME. 

12. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional 
GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in 
the new MME for this UE then the new MME sends an Update Location Request (MME Identity, IMSI, ULR- 
Flags, MME Capabilities, Homogeneous Support of IMS Over PS Sessions, UE SRVCC capability) message to 
the HSS. ULR-Flags indicates that update location is sent from an MME and the MME registration shall be 
updated in HSS. The HSS does not cancel any SGSN registration. The MME capabilities indicate the MME's 
support for regional access restrictions functionality. Homogenous Support of IMS Over PS Sessions indicates 
whether or not "IMS Voice over PS Sessions" is supported homogeneously in all TAs the serving MME. 

If the MME determines that only the UE SRVCC capability has changed, the MME sends a Notify Request to 
the HSS to inform about the changed UE SRVCC capabihty. 

If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location 
procedure or proceed even if the update location fails. 
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13. The HSS sends the message Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type 
set to Update Procedure. 

14. If the timer started in step 4 is not running, the old MME removes the MM context. Otherwise, the contexts are 
removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE 
initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME 
acknowledges with the message Cancel Location Ack (IMSl). 

15. When old S4 SGSN receives the Context Acknowledge message and if the UE is in lu Connected, the old 
S4 SGSN sends an lu Release Command message to the RNC after the timer started in step 4 has expired. 

16. The RNC responds with an lu Release Complete message. 

17. The HSS acknowledges the Update Location Request message by sending an Update Location Ack (IMSI, 
Subscription Data) message to the new MME. If the Update Location is rejected by the HSS, the new MME 
rejects the TAU Request from the UE with an appropriate cause. The Subscription Data may contain the CSG 
subscription data for the PLMN. 

If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID is contained 
in the CSG subscription and is not expired. If the CSG ID is not present or expired, the MME shall send a 
Tracking Area Update reject message to the UE with an appropriate cause value. The UE shall remove the CSG 
ID from its Allowed CSG list if present. If the UE has ongoing emergency bearer services no CSG access control 
shall be performed. 

If all checks are successful then the new MME constructs a context for the UE. 

18. If the MME has changed, when the timer started in step 4 expires the old MME/old S4 SGSN releases any local 
MME or SGSN bearer resources and additionally the old MME/old S4 SGSN deletes the EPS bearer resources 
by sending the Delete Session Request (Cause, Operation Indication) messagesto the old Serving GW if it 
received the Serving GW change indication in the Context Acknowledge message in step 7. When the Operation 
Indication flag is not set, that indicates to the old Serving GW that the old Serving GW shall not initiate a delete 
procedure towards the PDN GW. If ISR is activated the Cause indicates to the old S-GW that the old S-GW shall 
delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN 
node. 

If the MME has not changed, step 1 1 triggers the release of the EPS bearer resources at the old Serving GW. 

19. The Serving GW acknowledges with Delete Session Response (Cause) messages. The Serving GW discards any 
packets buffered for the UE. 

20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to 
access the TA: 

The MME rejects the Tracking Area Update Request with an appropriate cause to the UE. 

For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency 
services, the new MME accepts the Tracking Area Update Request and deactivates all non-emergency PDN 
connections as specified in clause 5.10.3. If the Tracking Area Update procedure is initiated in ECM-IDLE 
state, all non-emergency EPS bearers are deactivated by the Tracking Area Update procedure without bearer 
deactivation signalling between the UE and the MME. 

The MME sends a TAU Accept (GUTI, TAI list, EPS bearer status, NAS sequence number, NAS-MAC, IMS 
Voice over PS session supported. Emergency Service Support indicator, LCS Support Indication) message to the 
UE. If the active flag is set the MME may provide the eNodeB with Handover Restriction List. GUTI is included 
if the MME allocates a new GUTI. If the "active flag" is set in the TAU Request message the user plane setup 
procedure can be activated in conjunction with the TAU Accept message. The procedure is described in detail in 
TS 36.300 [5]. The message sequence should be the same as for the UE triggered Service Request procedure 
specified in clause 5.3.4.1 from the step when MME establishes the bearer(s). The MME indicates the EPS 
bearer status IE to the UE. The UE removes any internal resources related to bearers that are not marked active 
in the received EPS bearer status. Handover Restriction List is described in clause 4.3.5.7 "Mobility 
Restrictions". The MME sets the IMS Voice over PS session supported as described in clause 4.3.5.8. The 
Emergency Service Support indicator informs the UE that Emergency bearer services are supported. LCS 
Support Indication indicates whether the network supports the EPC-MO-LR and/or CS-MO-LR as described in 
TS 23.271 [57]. 
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When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to 
"GUTI". 

For a S-GW change, ISR Activated is never indicated by the MME as it needs a RAU with the same S-GW first 
to activate ISR. For an MME change, ISR is not activated by the new MME to avoid context transfer procedures 
with two old CN nodes. 

If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the 
TAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG 
selection is not supported if the UE has emergency bearers established. 

If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via 
a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with 
the SI -MME control message. Based on this information the RAN may perform differentiated treatment for 
CSG and non-CSG members. 

NOTE 6: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG 
ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

21. If GUTI was included in the TAU Accept, the UE acknowledges the received message by returning a TAU 
Complete message to the MME. 

When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated 
in ECM-CONNECTED state, the new MME releases the signalling connection with UE, according to 
clause 5.3.5. 

NOTE 7: The new MME may initiate E-RAB establishment (see TS 36.413 [36]) after execution of the security 
functions, or wait until completion of the TA update procedure. For the UE, E-RAB establishment may 
occur anytime after the TA update request is sent. 

In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME should not construct an MM context for the UE. In 
the case of receiving the subscriber data from HSS, the new MME may construct an MM context and store the 
subscriber data for the UE to optimize signalling between the MME and the HSS. A reject shall be returned to the UE 
with an appropriate cause and the S 1 connection shall be released. Upon return to idle, the UE shall act according to 
TS 23.122 [10]. 

The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context in the Context Response message and then store the new Maximum APN restriction value. 

The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of 
active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to 
maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more 
P-GWs and then deactivate the bearer context(s) that it cannot maintain as described in the clause "MME Initiated 
Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update. 

The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP values reserved 
for emergency services. 

NOTE 8: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward 
Relocation Request message as described in the clause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking 
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state. 
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Figure 5.3.3.2-1 : E-UTRAN Tracking Area Update without S-GW change 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 12 and 14 concern GTP 
based S5/S8. 

NOTE 2: In case of Tracking Area Update without MME change the signalling in steps 4, 5, 7 and steps 9-19 are 
skipped. A change of UE Time Zone, User CSG information or Serving Network is signalled in the next 
Service Request. 

1 . One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs. 
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2. The UE initiates a TAU procedure by sending, to the eNodeB, a Tracking Area Update Request (UE Core 
Network CapabiHty, MS Network CapabiHty, active flag, EPS bearer status, old GUTI, Old GUTI Type, last 
visited TAI, P-TMSI signature, additional GUTI, KSIsgsn, KSIasme, NAS sequence number, NAS-MAC, Voice 
domain preference and UE's usage setting) message together with RRC parameters indicating the Selected 
Network and the old GUMMEI. An exception is that, if the TAU was triggered for load re-balancing purposes 
(see clause 4.3.7.3), the old GUMMEI is not included in the RRC parameters. The UE shall set the Old GUTI 
Type to indicate whether the Old GUTI is a native GUTI or is mapped from a P-TMSI and RAI. 

If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI 
indicates this valid GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAI 
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in 
Annex H. When the UE is in connected mode (e.g. in URA_PCH) when it reselects to E-UTRAN, the UE shall 
set its TIN to "P-TMSI". 

If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE 
indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and 
the UE has a valid P-TMSI signature, the P-TMSI signature shall be included. 

The additional GUTI in the Tracking Area Update Request message allows the new MME to find any already 
existing UE context stored in the new MME when the old GUTI indicates a value mapped from a P-TMSI and 
RAI. 

The RRC parameter "old GUMMEI" takes its value from the identifier that is signalled as the old GUTI 
according to the rules above. For a combined MME/SGSN the eNodeB is configured to route the MME-code(s) 
of this combined node to the same combined node. This eNodeB is also configured to route MME-code(s) of 
GUTIs that are generated the UE's mapping of the P-TMSIs allocated by the combined node. Such an eNodeB 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 

The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent 
TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by the 
UE to activate the radio and SI bearers for all the active EPS Bearers by the TAU procedure. The UE's ISR 
capability is included in the UE Core Network Capability element. The EPS bearer status indicates each EPS 
bearer that is active in the UE. The TAU Request message shall be integrity protected by the NAS-MAC as 
described in TS 33.401 [41]. KSIasme is included if the UE has valid security parameters. NAS sequence number 
indicates the sequential number of the NAS message. 

KSIsGSN is included if the UE indicates a GUTI mapped from a P-TMSI in the information element "old GUTI". 

The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in 
clause 4.3.5.9. 

3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected 
Network. If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available or the UE 
indicates that the TAU procedure was triggered by load re-balancing, the eNodeB selects the MME as described 
in clause 4.3.8.3 on "MME Selection Function". The eNodeB forwards the TAU Request message together with 
the CSG access mode, CSG ID, TAIh-ECGI of the cell from where it received the message and with the Selected 
Network to the MME. CSG ID is provided by RAN if the UE sends the TAU Request message via a CSG cell or 
a hybrid cell. CSG access mode is provided if the UE sends the TAU Request message via a hybrid cell. If the 
CSG access mode is not provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell. 

4. The new MME differentiates the type of the old node, i.e. MME or SGSN, as specified in clause 4.3. 19, uses the 
GUTI received from the UE to derive the old MME/S4 SGSN address and sends a Context Request (old GUTI, 
MME Address, UE Validated, complete TAU Request message, P-TMSI Signature) message to the old 
MME/S4 SGSN to retrieve the user information. UE Validated indicates that the new MME has validated the 
integrity protection of the TAU message, e.g. based on native EPS security context for the UE. To validate the 
Context Request the old MME uses the complete TAU Request message and the old S4 SGSN uses the P-TMSI 
Signature and responds with an appropriate error if integrity check fails in old MME/S4 SGSN.. This shall 
initiate the security functions in the new MME. If the security functions authenticate the UE correctly, the new 
MME shall send a Context Request (IMSI, complete TAU Request message, MME Address, UE Validated) 
message to the old MME/S4 SGSN with the UE Validated set. If the new MME indicates that it has 
authenticated the UE or if the old MME/old S4 SGSN authenticates the UE, the old MME/old S4 SGSN starts a 
timer. 
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If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting 
unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and 
starting the timer also when it cannot validate the Context Request. 

5. If the Context Request is sent to an old MME the old MME responds with a Context Response (IMSI, ME 
Identity (if available), MSISDN, unused EPS Authentication Vectors, KSIasme, Kasme, EPS Bearer Context(s), 
Serving GW signalling Address and TEID(s), MS Info Change Reporting Action (if available), CSG Information 
Reporting Action (if available), UE Time Zone, UE Core Network Capability, UE Specific DRX Parameters) 
message. 

If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response (IMSI, 
ME Identity (if available), MSISDN, unused Authentication Quintets, CK, IK, KSIsgsn, EPS Bearer Context(s), 
Serving GW signalling Address and TEID(s), ISR Supported, MS Info Change Reporting Action (if available), 
CSG Information Reporting Action (if available), UE Time Zone, UE Core Network Capability, UE Specific 
DRX Parameters) message. The Authentication Quintets are maintained by the old S4 SGSN. 3GPP 
TS 33.401 [41] gives further details on the transfer of security related information. 

The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at the PDN 
GW(s) for uplink traffic and the TI(s), is part of the EPS Bearer Context. ISR Supported is indicated if the old 
SGSN and associated Serving GW are capable to activate ISR for the UE. 

The new MME shall ignore the UE Core Network Capability contained in the Context Response only when it 
has previously received an UE Core Network Capability in the Tracking Area Update Request. If the UE is not 
known in the old MME/old S4 SGSN or if the integrity check for the TAU request message fails, the old 
MME/old S4 SGSN responds with an appropriate error cause. 

If the UE receives emergency services from the old MME/old S4 SGSN and the UE is UlCCless, IMSI can not 
be included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the 
IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available. 

6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. The 
authentication functions are defined in clause 5.3.10 on "Security Function". Ciphering procedures are described 
in clause 5.3.10 on "Security Function". If GUTI allocation is going to be done and the network supports 
ciphering, the NAS messages shall be ciphered. 

If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the 
TAI sent by the eNodeB in Step 3 is different from that of the GUTI included in the TAU Request message, the 
MME shall delay authenticating the UE until after Step 21 (TAU Complete message). 

NOTE 3: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new 

PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE 
as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is 
used in the derivation of the Kasme key by both the network and the UE. 

If the new MME is configured to allow emergency services for unauthenticated UE the new MME behave as 
follows: 

where a UE has only emergency bearer services, the MME either skip the authentication and security 
procedure or accepts that the authentication may fail and continues the Tracking Area Update procedure; or 

where a UE has both emergency and non emergency bearer services and authentication fails, the MME 
continues the Tracking Area Update procedure and deactivates all the non-emergency PDN connections as 
specified in clause 5.10.3. 

7. If the old node is an old MME the new MME sends a Context Acknowledge message to the old MME. The old 
MME marks in its context that the information in the GWs and the HSS are invalid. This ensures that the MME 
updates the GWs and the HSS if the UE initiates a TAU procedure back to the MME before completing the 
ongoing TAU procedure. 

If the old node is an old S4 SGSN the MME sends a Context Acknowledge (ISR Activated) message to the old 
SGSN. Unless ISR Activated is indicated by the MME, the old S4 SGSN marks in its context that the 
information in the GWs is invalid. This ensures that the old S4 SGSN updates the GWs if the UE initiates a RAU 
procedure back to the old S4 SGSN before completing the ongoing TAU procedure. If ISR Activated is indicated 
to the old S4 SGSN, this indicates that the old S4 SGSN shall maintain its UE context including authentication 
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quintets and stop the timer started in step 4. In this case, if the Implicit Detach timer is running, the old S4 SGSN 
shall re-start it with a slightly larger value than the UE's GERAN/UTRAN Deactivate ISR timer. Also, in this 
case, if the old SGSN has maintained the Serving GW address for user plane and S4 GTP-U TEID, the old 
SGSN shall remove Serving GW address for user plane and S4 GTP-U TEID locally. When ISR Activated is not 
indicated and this timer expires the old SGSN deletes all bearer resources of that UE. As the Context 
Acknowledge from the MME does not include any S-GW change the S4 SGSN does not send any Delete 
Session Request message to the S-GW. The MME shall not activate ISR if the associated Serving GW does not 
support ISR. 

If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the MME shall 
send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the 
Identification and Context Request was never received. 

8. Void. 

9. If the MME has changed the new MME adopts the bearer contexts received from the old MME/SGSN as the 
UE's EPS bearer contexts to be maintained by the new MME. The MME establishes the EPS bearer(s) in the 
indicated order. The MME deactivates the EPS bearers which cannot be established. 

The MME verifies the EPS bearer status received from the UE with the EPS bearer contexts it maintains and 
releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context 
at all, the MME rejects the TAU Request. If the MME has changed the new MME sends a Modify Bearer 
Request (new MME address and TEID, ISR Activated, RAT type) message per PDN connection to the Serving 
GW. If there is no need for the SGW to send the signalling to the PDN GW, the MME may send Modify Access 
Bearers Request (new MME address and TEID) per UE to the Serving GW to optimize the signalling. The PDN 
GW address is indicated in the bearer contexts. If indicated, the information ISR Activated indicates that ISR is 
activated. If the PDN GW requested UE's location and/or User CSG information, the MME also includes the 
User Location Information IE and/or User CSG Information IE in this message. If the UE Time Zone has 
changed, the MME includes the UE Time Zone IE in this message. If the Serving Network has changed or if the 
MME has not received any old Serving Network information from the old MME/SGSN, the MME includes the 
new Serving Network IE in this message. In network sharing scenarios Serving Network denotes the serving 
core network. If the old node is an old MME at a Tracking Area Update with a MME change ISR Activated shall 
not be indicated. 

NOTE 4: The User CSG Information IE is only sent in step 9 if the "Active flag" is set in the TAU Request 

message. 

When the Modify Access Bearers Request or Modify Bearer Request does not indicate ISR Activated the S-GW 
deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on 
the S-GW reserved. 

10. If the RAT type has changed, or the Serving GW has received the User Location Information IE or the UE Time 
Zone IE or User CSG Information IE and/or the Serving Network IE from the MME in step 9, the Serving GW 
informs the PDN GW(s) about this information that e.g. can be used for charging, by sending the message 
Modify Bearer Request (RAT type) per PDN connection to the PDN GW(s) concerned. User Location 
Information IE and/or UE Time Zone IE and/or User CSG Information IE and/or Serving Network IE are also 
included if they are present in step 9. 

n . If dynamic PCC is deployed, and RAT type information or UE location information needs to be conveyed from 
the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by means of an IP-CAN 
Session Modification procedure as defined in TS 23.203 [6]. 

NOTE 5: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

12. The PDN GW updates its context field to allow DL PDUs to be routed to the correct Serving GW. PDN GW 
returns a Modify Bearer Response (MSISDN) to the Serving GW. The MSISDN is included if the PDN GW has 
it stored in its UE context. 

13. The Serving GW updates its bearer context. If ISR Activated is indicated in step 9 and RAT Type received in 
step 9 indicates E-UTRAN, then the Serving GW only updates the MME Control Plane Address stored locally 
and keep the SGSN related information unchanged. Also, in this case, if the Serving GW has maintained the 
SGSN address for user plane and S4 GTP-U TEID, the Serving GW removes the SGSN address for user plane 
and S4 GTP-U TEID locally. Otherwise the Serving GW shall update all of the information stored locally for 
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this UE with the related information received from the MME. This allows the Serving GW to route Bearer PDUs 
to the PDN GW when received from eNodeB. The Serving GW shall return a Modify Bearer Response (Serving 
GW address and TEID for uplink traffic) message to the new MME as a response to a Modify Bearer Request 
message, or a Modify Access Bearers Response (Serving GW address and TEID for uplink traffic) as a response 
to a Modify Access Bearers Request message. If the Serving GW cannot serve the MME Request in the Modify 
Access Bearers Request message without S5/S8 signalling or without corresponding Gxc signalling when PMIP 
is used over the S5/S8 interface, it shall respond to the MME with indicating that the modifications are not 
limited to Sl-U bearers, and the MME shall repeat its request using Modify Bearer Request message per PDN 
connection. 

14. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional 
GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in 
the new MME for this UE then the new MME informs the HSS of the change of MME by sending an Update 
Location Request (MME Id, IMSI, ULR-Flags, MME Capabilities, Homogenous Support of IMS Over PS 
Sessions, UE SRVCC capability) message to the HSS. ULR-Flags indicates that update location is sent from an 
MME and the MME registration shall be updated in HSS. The HSS does not cancel any SGSN registration. The 
MME capabilities indicate the MME's support for regional access restrictions functionality. Homogenous 
Support of IMS Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported 
homogeneously in all TAs in the serving MME. 

If the MME determines that only the UE SRVCC capability has changed, the MME sends a Notify Request to 
the HSS to inform about the changed UE SRVCC capabihty. 

If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location 
procedure or proceed even if the update location fails. 

15. The HSS sends a Cancel Location (IMSI, Cancellation type) message to the old MME with a Cancellation Type 
set to Update Procedure. 

16. When receiving a Cancel Location message and the timer started in step 4 is not running, the old MME removes 
the MM and bearer contexts. Otherwise, the contexts are removed when the timer expires. It also ensures that the 
MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the 
ongoing TAU procedure to the new MME. The old MME acknowledges with a Cancel Location Ack (IMSI) 
message. 

NOTE 6: ISR Activated is never indicated from new to old MME. 

So an old MME deletes all the bearer resources of the UE in any case when the timer started in step 4 expires, 
which is independent on receiving a Cancel Location message. 

17. When receiving the Context Acknowledge message and if the UE is lu Connected, the old SGSN sends an lu 
Release Command message to the RNC after the timer started in step 4 has expired. 

18. The RNC responds with an lu Release Complete message. 

19. The HSS acknowledges the Update Location Request by returning an Update Location Ack (IMSI, Subscription 
Data) message to the new MME after the cancelling of the old MME context is finished. If the Update Location 
is rejected by the HSS, the MME rejects the TAU Request from the UE with an appropriate cause sent in the 
TAU Reject message to the UE. If all checks are successful, the MME constructs an MM context for the UE. 
The Subscription Data may contain the CSG subscription data for the PLMN. 

If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID is contained 
in the CSG subscription and is not expired. If the CSG ID is not present or expired, the MME shall send a 
Tracking Area Update reject message to the UE with an appropriate cause value. The UE shall remove the CSG 
ID from its Allowed CSG list if present. 

20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to 
access the TA: 

The MME rejects the Tracking Area Update Request with an appropriate cause to the UE. 

For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency 
services, the new MME accepts the Tracking Area Update Request and deactivates all non-emergency PDN 
connections as specified in clause 5.10.3. If the Tracking Area Update procedure is initiated in ECM-IDLE 
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state, all non-emergency EPS bearers are deactivated by the Tracking Area Update procedure without bearer 
deactivation signalling between the UE and the MME. 

The MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status, NAS 
sequence number, NAS-MAC, ISR Activated, IMS Voice over PS session supported. Emergency Service 
Support indicator, LCS Support Indication) message. If the active flag is set the Handover Restriction List may 
be sent to eNodeB as eNodeB handles the roaming restrictions and access restrictions in the Intra E-UTRAN 
case. If the "active flag" is set in the TAU Request message the user plane setup procedure is activated in 
conjunction with the TAU Accept message. The procedure is described in detail in TS 36.300 [5]. The message 
sequence should be the same as for the UE triggered Service Request procedure specified in clause 5.3.4.1 from 
the step when MME establish the bearers(s). The EPS bearer status indicates the active bearers in the network. 
The UE removes any internal resources related to bearers not marked active in the received EPS bearer status. If 
ISR Activated is indicated to the UE, this indicates that its P-TMSI and RAI shall remain registered with the 
network and shall remain valid in the UE. At a Tracking Area Update with an MME change ISR Activated shall 
not be indicated. At a Tracking Area Update without an MME change, if ISR is activated for the UE when the 
MME receives the Tracking Area Update Request, the MME should maintain ISR by indicating ISR Activated in 
the Tracking Area Update Accept message. Handover Restriction List is described in clause 4.3.5.7 "Mobility 
Restrictions". The MME sets the IMS Voice over PS session supported as described in clause 4.3.5.8. The 
Emergency Service Support indicator informs the UE that Emergency bearer services are supported. LCS 
Support Indication indicates whether the network supports the EPC-MO-LR and/or CS-MO-LR as described in 
TS 23.271 [57]. 

When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to 
"GUTI". When ISR Activated is indicated and the UE's TIN indicates "GUTI" the UE's TIN shall not be 
changed. When ISR Activated is indicated and the TIN is "P-TMSI" or "RAT-related TMSI" the UE shall set its 
TIN to "RAT-related TMSI". 

For an MME change ISR is not activated by the new MME to avoid context transfer procedures with two old CN 
nodes. 

For an emergency attached UE, emergency ISR is not activated. 

If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving 
TAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG 
selection is not supported if the UE has emergency bearers established. 

If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via 
a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with 
the SI -MME control message. Based on this information the RAN may perform differentiated treatment for 
CSG and non-CSG members. 

NOTE 7: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG 
ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

21. If the GUTI was changed the UE acknowledges the new GUTI by returning a Tracking Area Update Complete 

message to the MME. 

When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated 
in ECM-CONNECTED state, the MME releases the signalling connection with UE, according to clause 5.3.5. 

NOTE 8: The new MME may initiate E-RAB establishment (see TS 36.413 [36]) after execution of the security 
functions, or wait until completion of the TA update procedure. For the UE, E-RAB establishment may 
occur anytime after the TA update request is sent. 

In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME should not construct an MM context for the UE. In 
the case of receiving the subscriber data from HSS, the new MME may construct an MM context and store the 
subscriber data for the UE to optimize signalling between the MME and the HSS. A reject shall be returned to the UE 
with an appropriate cause and the S 1 connection shall be released. Upon return to idle, the UE shall act according to 
TS 23.122 [10]. 
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If the new MME is unable to update the bearer context in one or more P-GWs, the new MME shall deactivate the 
corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This 
shall not cause the MME to reject the tracking area update. 

The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context in the Context Response message and then store the new Maximum APN restriction value. 

The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of 
active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to 
maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more 
P-GWs and then deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated 
Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update. 

The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP values reserved 
for emergency services. 

NOTE 9: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward 
Relocation Request message as described in clause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking 
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state. 

If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access 
non-PS services until a successful location update is performed. 

5.3.3.3 Routing Area Update with MME interaction and without S-GW change 

The Routing Area Update without S-GW change procedure takes place when a UE that is registered with an MME 
selects a UTRAN or GERAN cell and the S-GW is not changed by the procedure. In this case, the UE changes to a 
Routing Area that the UE has not yet registered with the network. This procedure is initiated by an ECM-IDLE state UE 
and may also be initiated if the UE is in ECM-CONNECTED state. The RA update case is illustrated in Figure 5.3.3.3- 
I. 

NOTE 1: This procedure covers the MME to 2G or 3G SGSN RAU. 
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Figure 5.3.3.3-1 : Routing Area Update withi IVIIVIE interaction and withiout S-GW chiange 

NOTE 2: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 8 and 10 
concern GTP based S5/S8. 

1. The UE selects a UTRAN or GERAN cell. This cell is in a Routing Area that the UE not yet registered with the 
network, or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in 
ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell Change (NACC). 
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2a. The UE sends a Routing Area Update Request (old P-TMSI, P-TMSI Type, old RAI, UE Core Network 

Capability, MS Network Capability, P-TMSI Signature, additional P-TMSI/RAI, KSI, Voice domain preference 
and UE's usage setting) message to the new SGSN. The UE shall set the P-TMSI Type to indicate whether the P- 
TMSI is a native P-TMSI or is mapped from a GUTI. 

If the UE's internal TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the 
old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid 
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to 
a P-TMSI and an RAI is specified in TS 23.003 [9]. 

If the UE holds a valid P-TMSI and related RAI and the old P-TMSI and old RAI indicate a P-TMSI/RAI 
mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI. 

The old P-TMSI is indicated in the RAU Request message for lu-mode only. For Gb mode the TLLI is derived 
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is 
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is 
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to 
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) 
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 

If the UE has a follow-on request, i.e. if there is pending uplink traffic (signalling or data), the 3G SGSN may 
use, as an implementation option, the follow-on request indication to release or keep the lu connection after the 
completion of the RA update procedure. 

KSI is mapped from an eKSI identifying a Kasme if the UE indicates a P-TMSI mapped from GUTI in the 
information element "old P-TMSI". KSI identifies a (CK, IK) pair if the UE indicates a P-TMSI in the 
information element "old P-TMSI". 

The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in 
clause 4.3.5.9. 

2b. The RNC shall add the Routing Area Identity, CSG access mode, CSG ID before forwarding the message to the 
SGSN. This RA identity corresponds to the RAI in the MM system information sent by the RNC to the UE. The 
BSS shall add the Cell Global Identity (CGI) of the cell where the UE is located before passing the message to 
the new SGSN. CSG ID is provided by RAN if the UE sends the RAU Request message via a CSG cell or a 
hybrid cell. CSG access mode is provided if the UE sends the RAU Request message via a hybrid cell. If the 
CSG access mode is not provided but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell. 

3. The new S4 SGSN determines the type of the old node, i.e. MME or SGSN, as specified in clause 4.3. 19, uses 
the old RAI received from the UE to derive the old MME address, and sends a Context Request (P-TMSI, old 
RAI, New SGSN Address, P-TMSI Signature) message to the old MME to get the context for the UE. To 
validate the Context Request the old MME uses a N AS token mapped from the P-TMSI Signature. If the UE is 
not known in the old MME, the old MME responds with an appropriate error cause. If integrity check fails in the 
old MME, the old MME responds with an appropriate error cause which shall initiate the security functions in 
the new S4 SGSN. If the security functions authenticate the UE correctly, the new S4 SGSN shall send a Context 
Request (IMSI, old RAI, New SGSN Address, UE Validated) message to the old MME.UE Validated indicates 
that the new S4 SGSN has authenticated the UE. If the new S4 SGSN indicates that it has authenticated the UE 
or if the old MME authenticates the UE, the old MME starts a timer. 

If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated 
UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it 
cannot validate the Context Request. 

4. The old MME responds with one Context Response (IMSI, ME Identity (if available), MSISDN, KSI, CK, IK, 
unused Authentication Quintets, EPS Bearer Contexts, Serving GW signalling Address and TEID(s), ISR 
Supported, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), 
UE Time Zone, UE Core Network Capability, UE Specific DRX Parameters) message. The PDN GW Address 
and TEID(s) (for GTP -based S5/S8) or GRE Keys (PMIP-based S5/S8) for uplink traffic and control plane, and 
the TI(s) is part of the EPS Bearer context(s). The unused Authentication Quintets in the MM Context may be 
sent if stored by the MME and the MME received the unused Authentication Quintets from the same SGSN 
previously. ISR Supported is indicated if the old MME and associated Serving GW are capable to activate ISR 
for the UE. 
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If the UE receives emergency services from the old MME and the UE is UlCCless, IMSI can not be included in 
the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the IMSI shall be 
marked as unauthenticated. Also, in this case, security parameters are included only if available. 

The new S4 SGSN shall ignore the UE Core Network Capability contained in the Context Response only when it 
has previously received an UE Core Network Capability in the Routing Area Update Request. If UE is not 
known in the old MME, the old MME responds with an appropriate error cause. 

The new SGSN maps the EPS bearers to PDP contexts 1-to-l and maps the EPS Bearer QoS parameter values of 
an EPS bearer to the Release 99 QoS parameter values of a PDP context as defined in Annex E. The PDP 
context(s) are established in the indicated order. The SGSN deactivates the PDP contexts which cannot be 
established. 

5. Security functions may be executed. Procedures are defined in clause 5.3. 10 on "Security Function". 

If the new SGSN is configured to allow emergency services for unauthenticated UE the new SGSN behave as 
follows: 

where a UE has only emergency bearer services, the SGSN either skip the authentication and security 
procedure or accepts that the authentication may fail and continues the Routing Area Update procedure; or 

where a UE has both emergency and non emergency bearer services and authentication fails, the SGSN 
continues the Routing Area Update procedure and deactivates all the non-emergency PDP contexts as 
specified in TS 23.060 [7]. 

6. The new S4 SGSN sends a Context Acknowledge (ISR Activated) message to the old MME. Unless ISR is 
indicated by the new S4 SGSN, the old MME marks in its context that the information in the GWs is invalid. 
This ensures that the old MME updates the GWs if the UE initiates a TAU procedure back to the old MME 
before completing the ongoing RAU procedure. ISR Activated indicates to the old MME that it shall maintain 
the UE's contexts and the MME stops the timer started in step 3. In this case, if the Implicit Detach timer is 
running, the old MME shall re-start it with a slightly larger value than the UE's E-UTRAN Deactivate ISR timer. 
When ISR Activated is not indicated and this timer expires the old MME deletes all bearer resources of that UE. 
As the Context Acknowledge from the new S4 SGSN does not include any S-GW change the old MME does not 
send any Delete Session Request message to the S-GW. The SGSN shall not activate ISR if the associated 
Serving GW does not support ISR. 

If the security functions do not authenticate the UE correctly, then the RAU is rejected, and the new S4 SGSN 
sends a reject indication to the old MME. The old MME shall continue as if the Identification and Context 
Request was never received. 

7. In this procedure flow the Serving GW is not relocated. The SGSN sends a Modify Bearer Request (new SGSN 
Address and TEID, RAT type, ISR Activated) message per PDN connection to the Serving GW. If indicated, the 
information ISR Activated indicates that ISR is activated. If the PDN GW requested UE's location info and/or 
User CSG information, the SGSN also includes the User Location Information IE and/or User CSG information 
IE in this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. 
If the Serving Network has changed or if the SGSN has not received any old Serving Network information from 
the old MME, the SGSN includes the new Serving Network IE in this message. In network sharing scenarios 
Serving Network denotes the serving core network. 

When the Modify Bearer Request does not indicate ISR Activated the S-GW deletes any ISR resources by 
sending a Delete Bearer Request to the other CN node that has bearer resources on the S-GW reserved. RAT 
type indicates a change in radio access. 

If ISR Activated is indicated or SGSN and SGW are configured to release S4 U-Plane when EPS Bearer 
Contexts associated with the released RABs are to be preserved, the SGSN does not send SGSN address and 
TEID for U-Plane in Modify Bearer Request. 

NOTE 3: The User CSG Information IE is not sent in step 7 if the "follow-on request indication" indicates releasing 
the lu connection after the completion of the RA update procedure. 

8. If the RAT type has changed or the Serving GW has received the User Location Information IE and/or the UE 
Time Zone IE and/or User CSG information IE and/or the Serving Network IE from the MME in step 7 the 
Serving GW informs the PDN GW(s) about the change of this information that e.g. can be used for charging, by 
sending the message Modify Bearer Request (RAT type) per PDN connection to the PDN GW(s) concerned. 
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User Location Information IE and/or UE Time Zone IE and/or User CSG information IE and/or Serving 
Network IE are also included if they are present in step 7. 

9. If dynamic PCC is deployed, and RAT type information or UE location information needs to be conveyed from 
the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by means of an IP-CAN 
Session Modification procedure as defined in TS 23.203 [6]. 

NOTE 4: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

10. The PDN GW updates its context field and returns a Modify Bearer Response (MSISDN) message to the Serving 
GW. MSISDN is included if the PDN GW has it stored in its UE context. 

11. The Serving GW updates its context fields. If ISR Activated is indicated in step 7 and RAT Type received in step 
7 indicates UTRAN or GERAN, then the Serving GW only updates the SGSN Control Plane Address and keeps 
the MME related information unchanged. Otherwise the Serving GW shall update all of the information stored 
locally for this UE with the related information received from the SGSN. Then the Serving GW returns a Modify 
Bearer Response (Serving GW address and TEID for uplink traffic) message. 

12. The new SGSN verifies whether it holds subscription data for the UE identified by the P-TMSI, the additional 
PTMSI/RAI or by the IMSI received with the context data from the old CN node. The additional P-TMSI/RAI 
allows the new SGSN to find any already existing UE context stored in the new SGSN. If there are no 
subscription data in the new SGSN for this UE then the new SGSN informs the HSS of the change of the SGSN 
by sending an Update Location (SGSN Number, SGSN Address, IMSI, Homogenous Support of IMS Over PS 
Sessions, UE SRVCC capability) message to the HSS. Homogenous Support of IMS Over PS Sessions indicates 
whether or not "IMS Voice over PS Sessions" is supported homogeneously in all RAs in the serving SGSN. 

13. The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with the Cancellation 
Type set to Update Procedure. 

When receiving the Cancel Location message the old SGSN removes all the UE contexts. The old SGSN 
acknowledges with a Cancel Location Ack (IMSI) message. 

14. When receiving the Context Acknowledge message from the new SGSN and if the old MME has an Sl-MME 
association for the UE, the source MME sends a Sl-U Release Command to the source eNodeB after the timer 
started in step 3 has expired. The RRC connection is released by the source eNodeB. The source eNodeB 
confirms the release of the RRC connection and of the Sl-U connection by sending a Sl-U Release Complete 

message to the source MME. 

15. The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription 
Data) to the new SGSN. If the Update Location is rejected by the HSS, the new SGSN rejects the RAU Request 
from the UE with an appropriate cause. The Subscription Data may contain the CSG subscription data for the 
PLMN. 

If the UE initiates the RAU procedure at a CSG cell, the new S4 SGSN shall check whether the CSG ID is 
contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the S4 SGSN shall 
send a RAU reject message to the UE with an appropriate cause value. The UE shall remove the CSG ID from 
its Allowed CSG list if present. 

16. Void. 

17. Void. 

18. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to 
access the RA: 

For UEs with ongoing emergency bearer services, the new SGSN accept the Routing Area Update Request 
and deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 in TS 23.060 [7]. .If the 
Routing Area Update procedure is initiated in PMM-IDLE/STANDBY state, all non-emergency PDP 
Contexts are deactivated by the Routing Area without PDP Context deactivation signalling between the UE 
and the SGSN 

For all other cases, the new SGSN rejects Routing Area Update Request with an appropriate cause to the UE 
and notifies the HSS of rejection (details of this notification is covered in stage 3). 
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The new SGSN responds to the UE with a Routing Area Update Accept (P-TMSI, P-TMSI signature, ISR 
Activated, Emergency Service Support indicator) message to the UE. P-TMSI is included if the SGSN allocates 
a new P-TMSI. The Emergency Service Support indicator informs the UE that Emergency bearer services are 
supported over UTRAN. 

If ISR Activated is indicated to the UE, its GUTI and list of TAs shall remain registered with the network and 
shall remain valid in the UE. 

When receiving the RAU Accept message and there is no ISR Activated indication the UE shall set its TIN to 
"P-TMSI". When ISR Activated is indicated and the UE's TIN indicates "P-TMSI" the TIN shall not be changed. 
When ISR Activated is indicated and the UE's TIN indicates "GUTI" or "RAT-related TMSI" the UE shall set its 
TIN to "RAT-related TMSI". 

If an SGSN change ISR is not activated by the new SGSN to avoid context transfer procedures with two old CN 
nodes. 

If the RAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the 
RAU Accept shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG selection is 
not supported if the UE has emergency bearers established. 

If the user plane setup is performed in conjunction with the RAU Accept message and the RAU is performed via 
a hybrid cell, then the SGSN shall send an indication whether the UE is a CSG member to the RAN along with 
the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and 
non-CSG members. 

NOTE 5: If the UE receives a RAU Accept message via a hybrid cell, the UE does not add the corresponding CSG 
ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

19. If P-TMSI was included in the Routing Area Update Accept message, the UE acknowledges the new P-TMSI by 
returning a Routing Area Update Complete message to the SGSN. 

20. For lu-mode, if the UE has uplink data or signalling pending it shall send a Service Request (P-TMSI, CKSN, 
Service Type) message to the new SGSN. If a P-TMSI was allocated in step 18, that P-TMSI is the one included 
in this message. Service Type specifies the requested service. Service Type shall indicate one of the following: 
Data or Signalling. 

21 . If the UE has sent the Service Request, the new 3G SGSN requests the RNC to establish a radio access bearer by 
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP SNDs, GTP SNUs, PDCP SNUs) 
message to the RNC. If Direct Tunnel is established the SGSN provides to the RNC the Serving GW's Address 
for User Plane and TEID for uplink data. 

22. If the SGSN established Direct Tunnel in step 21) it shall send Modify Bearer Request per PDN connection to 
the Serving GW and include the RNC's Address for User Plane and downlink TEID for data. The Serving GW 
updates the Address for User Plane and TEID for downlink data and return a Modify Bearer Response. 

NOTE 6: EPS does not support any CAMEL procedures. 

NOTE 7: The new SGSN may initiate RAB establishment after execution of the security functions (step 5), or wait 
until completion of the RA update procedure. For the MS, RAB establishment may occur anytime after 
the RA update request is sent (step 2). 

In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new SGSN should not construct an MM context. In the case of 
receiving the subscriber data from HSS, the new SGSN may construct an MM context and store the subscriber data for 
the UE to optimize signalling between the SGSN and the HSS. A reject shall be returned to the UE with an appropriate 
cause and the PS signalling connection shall be released. Upon return to idle, the UE shall act according to 
TS 23.122 [10]. 

If the network supports the MOCN configuration for network sharing, the SGSN may, if the UE is not a 'Network 
Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as 
described in TS 23.251 [24] instead of rejecting the routing area update. 
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If the new SGSN is unable to update the bearer context in one or more P-GWs, the new SGSN shall deactivate the 
corresponding bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure" of 
TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update. 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context in the Context Response message and then store the new Maximum APN restriction value. 

The PDP contexts shall be prioritized by the new SGSN. If the new SGSN is unable to support the same number of 
active PDP contexts as received from the old MME, the prioritisation is used to decide which PDP contexts to maintain 
active and which ones to delete. In any case, the new SGSN shall first update all PDP contexts in one or more P-GWs 
and then deactivate the PDP context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context 
Deactivation Procedure" of TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update. 

NOTE 8: If the UE was in PMM-CONNECTED state the bearer contexts are sent already in the Forward 
Relocation Request message as described in clause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing Area 
Update Reject (Cause) message, the UE shall enter PMM DETACHED state. 

If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access 
non-PS services until a successful location update is performed. 

5.3.3.4 Void 



5.3.3.5 Void 



5.3.3.6 Routing Area Update with IVIIVIE interaction and with S-GW change 

The Routing Area Update with S-GW change procedure takes place when a UE that is registered with an MME selects 
a UTRAN or GERAN cell and the S-GW is changed by the procedure. In this case, the UE changes to a Routing Area 
that the UE has not yet registered with the network. This procedure is initiated by an ECM-IDLE state UE and may also 
be initiated if the UE is in ECM-CONNECTED state. This RA update case is illustrated in Figure 5.3.3.6-1. 

NOTE 1: This procedure covers the MME to 2G or 3G SGSN RAU. 
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Figure 5.3.3.6-1 : Routing Area Update with IVIIVIE interaction and with S-GW change 

NOTE 2: For a PMIP -based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 8 and 10 
concern GTP based S5/S8 
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1. The UE selects a UTRAN or GERAN cell. This cell is in a Routing Area that the UE not yet registered with the 
network or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in 
ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell Change (NACC). 

2a. The UE sends a Routing Area Update Request (old RAI, old P-TMSI, P-TMSI Type, UE Core Network 

Capability, MS Network Capability, P-TMSI Signature, additional P-TMSI/RAI, KSI, Voice domain preference 
and UE's usage setting) message to the new SGSN. The UE shall set the P-TMSI Type to indicate whether the P- 
TMSI is a native P-TMSI or is mapped from a GUTI. 

If the UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the old 
P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a vaHd 
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to 
a P-TMSI and an RAI is specified in TS 23.003 [9]. 

If the UE holds a valid P-TMSI and related RAI and the old P-TMSI and old RAI indicate a P-TMSI/RAI 
mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI. 

The old P-TMSI is indicated in the RAU Request message for lu-mode only. For Gb mode the TLLI is derived 
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is 
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is 
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to 
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) 
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 

If the UE has a follow-on request, i.e. if there is pending uplink traffic (signalling or data), the 3G-SGSN may 
use, as an implementation option, the follow-on request indication to release or keep the lu connection after the 
completion of the RA update procedure. 

KSI is mapped from an eKSI identifying a Kasme if the UE indicates a P-TMSI mapped from GUTI in the 
information element "old P-TMSI". KSI identifies a (CK, IK) pair if the UE indicates a P-TMSI in the 
information element "old P-TMSI". 

The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in 
clause 4.3.5.9. 

2b. The RNC shall add the Routing Area Identity, CSG access mode, CSG ID before forwarding the message to the 
SGSN. This RA identity corresponds to the RAI in the MM system information sent by the RNC to the UE. The 
BSS shall add the Cell Global Identity (CGI) of the cell where the UE is located before passing the message to 
the new SGSN. CSG ID is provided by RAN if the UE sends the RAU Request message via a CSG cell or a 
hybrid cell. CSG access mode is provided if the UE sends the RAU Request message via a hybrid cell. If the 
CSG access mode is not provided but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell. 

3. The new S4 SGSN determines the type of the old node, i.e. MME or SGSN, as specified in clause 4.3. 19, uses 
the old RAI received from the UE to derive the old MME address, and the new S4 SGSN sends a Context 
Request (P-TMSI, old RAI, New SGSN Address, P-TMSI Signature) message to the old MME to get the context 
for the UE. To validate the Context Request the old MME uses a NAS token mapped from the P-TMSI 
Signature. If the UE is not known in the old MME, the old MME responds with an appropriate error cause. If 
integrity check fails in the old MME, the old MME responds with an appropriate error cause which should 
initiate the security functions in the new S4 SGSN. If the security functions authenticate the UE correctly, the 
new S4 SGSN shall send a Context Request (IMSI, old RAI, New SGSN Address, UE VaUdated) message to the 
old MME. UE Validated indicates that the new S4 SGSN has authenticated the UE. If the new S4 SGSN 
indicates that it has authenticated the UE or if the old MME authenticates the UE, the old MME starts a timer. 

If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated 
UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it 
cannot validate the Context Request. 

4. The old MME responds with a Context Response (MM Context, EPS Bearer Contexts, Serving GW signalling 
Address and TEID(s), MS Info Change Reporting Action (if available), CSG Information Reporting Action (if 
available), UE Time Zone and ISR Supported) message. The MM context contains security related information 
as well as other parameters (including IMSI and MSISDN) as described in clause 5.7.2 (Information Storage for 
MME). The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8) for 
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uplink traffic and control plane, and the TI(s) is part of the EPS Bearer context(s). The unused Authentication 
Quintets in the MM Context may be sent if stored by the MME and if the MME received the unused 
Authentication Quintets from the same SGSN previously. 

If the UE receives only emergency services from the old MME and the UE is UlCCless, IMSI can not be 
included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the 
IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available. 
ISR Supported is indicated if the old MME and associated Serving GW are capable to activate ISR for the UE. 

The new SGSN shall ignore the UE Core Network Capability in the MM Context of the Context Response only 
when it has previously received an UE Core Network Capability in the Routing Area Request. If UE is not 
known in the old MME, the old MME responds with a appropriate error cause. 

The new SGSN maps the EPS bearers to PDP contexts 1-to-l and maps the EPS Bearer QoS parameter values of 
an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E. The PDP 
context(s) are established in the indicated order. The SGSN deactivates the PDP contexts which cannot be 
established. 

5. Security functions may be executed. Procedures are defined in clause 5.3. 10 on "Security Function". 

For ongoing emergency services only, if the new SGSN is configured to support emergency services in limited 
service state, it may skip the authentication procedure or proceed even if authentication fails. If the new SGSN 
does not support emergency services in limited service state, then it rejects the RAU request with an appropriate 
reject cause. 

6. The new SGSN determines to relocate the Serving GW. The Serving GW is relocated when the old Serving GW 
cannot continue to serve the UE. The new SGSN may also decide to relocate the Serving GW if a new Serving 
GW is expected to serve the UE longer and/or with a more optimal UE to PDN GW path, or if a new Serving 
GW can be co-located with the PDN GW. Selection of a new Serving GW is performed according to 

clause 4.3.8.2 on "Serving GW selection function". 

The new SGSN sends a Context Acknowledge (Serving GW change indication) message to the old MME. 
Serving GW change indication indicates a new Serving GW has been selected. The old MME marks in its 
context that the information in the GWs is invalid. This ensures that the old MME updates the GWs if the UE 
initiates a TAU procedure back to the old MME before completing the ongoing RAU procedure. The old MME 
deletes all bearer resources of the UE when the timer started in step 3 expires. 

If the security functions do not authenticate the UE correctly, then the RAU is rejected, and the new S4 SGSN 
sends a reject indication to the old MME. The MME shall continue as if the Identification and Context Request 
was never received. 

7. In this procedure flow the Serving GW is relocated. The SGSN sends a Create Session Request (IMSI, bearer 
contexts, SGSN Address and TEID for the control plane, RAT Type, Type, the Protocol Type over S5/S8, 
Serving Network, UE Time Zone, etc) message per PDN connection to the selected new Serving GW. The PDN 
GW address is indicated in the bearer contexts. Type indicates to the Serving GW to send the Modify Bearer 
Request to the PDN GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be 
used over S5/S8 interface. RAT type indicates a change in radio access. If the PDN GW requested UE's location 
and/or User CSG information, the SGSN also includes the User Location Information IE and/or User CSG 
Information IE in this message. 

NOTE 3: The User CSG Information IE is not sent in step 7 if the "follow-on request indication" indicates releasing 
the lu connection after the completion of the RA update procedure. 

8. The new Serving GW sends the message Modify Bearer Request (Serving GW Address, Serving GW TEID, 
RAT type. Serving Network) per PDN connection to the PDN GW concerned. User Location Information IE 
and/or UE Time Zone IE and/or User CSG Information IE are also included if they are present in step 7. 

9. If dynamic PCC is deployed, and RAT type information or UE location information or UE Time Zone needs to 
be conveyed from the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by 
means of an IP -CAN Session Modification procedure as defined in TS 23.203 [6]. 

NOTE 4: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 
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10. The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN) message 
to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. 

1 1 . The new Serving GW updates its bearer context. This allows the Serving GW to route Bearer PDUs to the PDN 
GW when received from RNC. The new Serving GW returns a Create Session Response (Serving GW address 
and TEID, PDN GW Address and TElDs (for GTP-based S5/S8) or GRE keys (for PMlP-based S5/S8) at the 
PDN GW(s) for uplink traffic) message to the SGSN. 

12. The new SGSN verifies whether it holds subscription data for the UE identified by the P-TMSI, the additional 
P-TMSl/RAl or by the IMSI received with the context data from the old CN node. The additional P-TMSl/RAl 
allows the new SGSN to find any already existing UE context stored in the new SGSN. If there are no 
subscription data in the new SGSN for this UE then the new SGSN informs the HSS of the change of SGSN by 
sending an Update Location (SGSN Number, SGSN Address, IMSl, Homogenous Support of IMS Over PS 
Session, UE SRVCC capability) message to the HSS. Homogenous Support of IMS Over PS Sessions indicates 
whether or not "IMS Voice over PS Sessions" is supported homogeneously in all RAs in the serving SGSN. 

13. The HSS sends a Cancel Location (IMSl, Cancellation Type) message to the old SGSN with the Cancellation 
Type set to Update Procedure. 

When receiving the Cancel Location message the old SGSN removes all the UE contexts. The old SGSN 
acknowledges with a Cancel Location Ack (IMSI) message. 

14. When receiving the Context Acknowledge message from the new S4 SGSN and if the old MME has an S 1 - 
MME association for the UE, the source MME sends a Sl-U Release Command to the source eNodeB after the 
timer started in step3 has expired. The RRC connection is released by the source eNodeB. The source eNodeB 
confirms the release of the RRC connection and of the Sl-U connection by sending a Sl-U Release Complete 
message to the source MME. 

15. The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription 
Data) to the new SGSN. If the Update Location is rejected by the HSS, the new SGSN rejects the RAU Request 
from the UE with an appropriate cause. The new SGSN validates the UE's presence in the (new) RA. If due to 
regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to be 
attached in the RA, the SGSN rejects the Routing Area Update Request with an appropriate cause to the UE and 
notifies the HSS of the rejection. The Subscription Data may contain the CSG subscription data for the PLMN. 

If the UE initiates the RAU procedure at a CSG cell, the new S4 SGSN shall check whether the CSG ID is 
contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the S4 SGSN shall 
send a RAU reject message to the UE with an appropriate cause value. The UE shall remove the CSG ID from 
its Allowed CSG list if present. 

16. When the timer started in step 3 expires and the old MME received the Serving GW change indication in the 
Context Acknowledge message, the old MME deletes the EPS bearer resources by sending Delete Session 
Request (Cause, Operation Indication) messages to the old Serving GW. The operation Indication flag is not set, 
that indicates to the old Serving GW that the old Serving GW shall not initiate a delete procedure towards the 
PDN GW. If ISR is activated the cause indicates to the old S-GW that the old S-GW shall delete the bearer 
resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. 

17. The old Serving GW acknowledges with Delete Session Response (Cause) messages. The old Serving GW 
discards any packets buffered for the UE. 

18. If due to regional subscription restrictions or access restrictions the UE is not allowed to access the RA: 

For UEs with ongoing emergency bearer services, the new SGSN accept the Routing Area Update Request and 
deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 of TS 23.060 [7]. If the Routing Area 
Update procedure is initiated in PMM-IDLE/STANDBY state, all non-emergency PDP Contexts are deactivated 
by the Routing Area Update procedure without PDP Context deactivation signalling between the UE and the 
SGSN. 

For all other cases, the new SGSN rejects Routing Area Update Request with an appropriate cause to the UE and 
notifies the HSS of rejection (details of this notification is specified in stage 3). 

The new SGSN responds to the UE with a Routing Area Update Accept (P-TMSI, P-TMSI Signature, 
Emergency Service Support indicator) message. The Emergency Service Support indicator informs the UE that 
Emergency bearer services are supported over UTRAN. 
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For an S-GW change ISR Activated is never indicated by the SGSN to the UE as it needs a TAU with the same 
S-GW first to activate ISR. For an SGSN change ISR is not activated by the new SGSN to avoid context transfer 
procedures with two old CN nodes. 

When receiving the RAU Accept message, as there is no ISR Activated indication, the UE shall set its TIN to 
"P-TMSI". 

If the RAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the 
RAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG 
selection is not supported if the UE has emergency bearers established. 

If the user plane setup is performed in conjunction with the RAU Accept message and the RAU is performed via 
a hybrid cell, then the SGSN shall send an indication whether the UE is a CSG member to the RAN along with 
the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and 
non-CSG members. 

NOTE 5: If the UE receives a RAU Accept message via a hybrid cell, the UE does not add the corresponding CSG 
ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

NOTE 6: When ISR Activated is indicated and the UE's TIN indicates "P-TMSI" the TIN is not changed. When 
ISR Activated is indicated and the UE's TIN indicates "GUTI" or "RAT-related TMSI" the UE shall set 
its TIN to "RAT-related TMSI". 

19. If the P-TMSI was included in the RAU Accept message, the UE acknowledges the new P-TMSI by returning a 
Routing Area Update Complete message to the SGSN. 

20. For lu-mode, if the UE has uplink data or signalling pending it shall send a Service Request (P-TMSI, CKSN, 
Service Type) message to the new SGSN. If a P-TMSI was allocated in step 18, that P-TMSI is the one included 
in this message. Service Type specifies the requested service. Service Type shall indicate one of the following: 
Data or Signalling. 

21 . If the UE has sent the Service Request, the new 3G SGSN requests the RNC to establish a radio access bearer by 
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP SNDs, GTP SNUs, PDCP SNUs) 
message to the RNC. If Direct Tunnel is established the SGSN provides to the RNC the Serving GW's Address 
for User Plane and TEID for uplink data. 

22. If the SGSN established Direct Tunnel in step 21) it shall send Modify Bearer Request to the Serving GW and 
include the RNC's Address for User Plane and downlink TEID for data. The Serving GW updates the Address 
for User Plane and TEID for downlink data and return a Modify Bearer Response. 

NOTE 7: EPS does not support any CAMEL procedures. 

In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions, access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) or because the SGSN cannot determine the HLR address to 
establish the locating updating dialogue, the new SGSN should not construct an MM context. In the case of receiving 
the subscriber data from HLR, the new SGSN may construct an MM context and store the subscriber data for the UE to 
optimize signalling between the SGSN and the HSS. A reject shall be returned to the UE with an appropriate cause and 
the PS signalling connection shall be released. Upon return to idle, the UE shall act according to TS 23.122 [10]. 

If the new SGSN is unable to update the bearer context in one or more P-GWs, the new SGSN shall deactivate the 
corresponding bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure" of 
TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update. 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context in the Context Response message and then store the new Maximum APN restriction value. 

The PDP contexts shall be prioritized by the new SGSN. If the new SGSN is unable to support the same number of 
active PDP contexts as received from old MME, the prioritisation is used to decide which PDP contexts to maintain 
active and which ones to delete. In any case, the new SGSN shall first update all PDP contexts in one or more P-GWs 
and then deactivate the PDP context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context 
Deactivation Procedure" of TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update. 

If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing Area 
Update Reject (Cause) message, the MS shall enter IDLE state. 
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5.3.4 Service Request procedures 
5.3.4.1 UE triggered Service Request 
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Figure 5.3.4.1-1 : UE triggered Service Request procedure 

For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 11 concern GTP- 
based S5/S8. 



1. The UE sends NAS message Service Request towards the MME encapsulated in an RRC message to the 
eNodeB. The RRC message(s) that can be used to carry the S-TMSI and this NAS message are described in 
TS 36.300 [5]. 

2. The eNodeB forwards NAS message to MME. NAS message is encapsulated in an Sl-AP: Initial UE Message 
(NAS message, TAl+ECGl of the serving cell, S-TMSl, CSG ID, CSG access Mode). Details of this step are 
described in TS 36.300 [5]. If the MME can't handle the Service Request it will reject it. CSG ID is provided if 
the UE sends the Service Request message via a CSG cell or a hybrid cell. CSG access mode is provided if the 
UE sends the Service Request message via a hybrid cell. If the CSG access mode is not provided but the CSG ID 
is provided, the MME shall consider the cell as a CSG cell. 

If a CSG ID is indicated and CSG access mode is not provided, and there is no subscription data for this CSG ID 
or the CSG subscription is expired, the MME rejects the Service Request with an appropriate cause. The UE 
shall remove the CSG ID of the cell where the UE has initiated the service request procedure from the Allowed 
CSG list, if present. 

For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP values reserved for emergency 
services, if CSG access restrictions do not allow the UE to get normal services the MME shall deactivate all non- 
emergency bearers and accept the Service Request. 

If LIPA is active for a PDN connection and if the cell accessed by the UE does not link to the L-GW where the 
UE inititiated the LIPA PDN Connection, the MME shall not request the establishment of the bearers of the 
LIPA PDN connection from the eNodeB in step 4 and shall request disconnection of the LIPA PDN connection 
according to clause 5. 10.3. If the UE has no other PDN connection then the MME shall reject the Service 
Request with an appropriate cause value resulting in the UE detaching, skip the following steps of the procedure 
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and initiate the release of the core network resources with the implicit MME-initiated Detach procedure 
according to clause 5.3.8.3. 

3. NAS authentication/security procedures as defined in clause 5.3.10 on "Security function" may be performed. 

4. The MME sends Sl-AP Initial Context Setup Request (Serving GW address, Sl-TEID(s) (UL), EPS Bearer 
QoS(s), Security Context, MME Signalling Connection Id, Handover Restriction List, CSG Membership 
Indication) message to the eNodeB. If there is a PDN connection established for Local IP Access, this message 
includes a Correlation ID for enabling the direct user plane path between the HeNB and the L-GW. This step 
activates the radio and SI bearers for all the active EPS Bearers. The eNodeB stores the Security Context, MME 
Signalling Connection Id, EPS Bearer QoS(s) and Sl-TEID(s) in the UE RAN context. The step is described in 
detail in TS 36.300 [5]. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". 

NOTE 2: In this release of the 3GPP specification the Correlation ID is set equal to the user plane PDN GW TEID 
(GTP -based S5) or GRE key (PMIP-based S5) which is specified in clause 5.3.2.1 and clause 5.10.2. 

The MME shall only request to establish Emergency EPS Bearer if the UE is not allowed to access the cell 
where the UE initiated the service request procedure due to CSG access restriction. 

If the Service Request is performed via a hybrid cell, CSG Membership Indication indicating whether the UE is a 
CSG member shall be included in the Sl-AP message from the MME to the RAN. Based on this information the 
RAN can perform differentiated treatment for CSG and non-CSG members. 

5. The eNodeB performs the radio bearer establishment procedure. The user plane security is established at this 
step, which is described in detail in TS 36.300 [5]. When the user plane radio bearers are setup. EPS bearer state 
synchronization is performed between the UE and the network, i.e. the UE shall locally remove any EPS bearer 
for which no radio bearers are setup and, if the radio bearer for a default EPS bearer is not established, the UE 
shall locally deactivate all EPS bearers associated to that default EPS bearer. 

6. The uplink data from the UE can now be forwarded by eNodeB to the Serving GW. The eNodeB sends the 
uplink data to the Serving GW address and TEID provided in the step 4. The Serving GW forwards the uplink 
data to the PDN GW. 

7. The eNodeB sends an Sl-AP message Initial Context Setup Complete (eNodeB address. List of accepted EPS 
bearers. List of rejected EPS bearers, SI TEID(s) (DL)) to the MME. This step is described in detail in 

TS 36.300 [5]. If the Correlation ID is included in step 4, the eNodeB shall use the included information to 
establish a direct user plane path to the L-GW and forward uplink data for Local IP Access accordingly. 

8. The MME sends a Modify Bearer Request message (eNodeB address, SI TEID(s) (DL) for the accepted EPS 
bearers. Delay Downlink Packet Notification Request, RAT Type) per PDN connection to the Serving GW. If 
the Serving GW supports Modify Access Bearers Request procedure and if there is no need for the Serving GW 
to send the signalling to the PGW, the MME may send Modify Access Bearers Request (eNodeB address(es) and 
TEIDs for downlink user plane for the accepted EPS bearers. Delay Downlink Packet Notification Request) per 
UE to the Serving GW to optimize the signalling. The Serving GW is now able to transmit downlink data 
towards the UE. The usage of the Delay Downlink Packet Notification Request Information Element is specified 
in clause 5.3.4.2 below. If the PDN GW requested UE's location and/or User CSG information and the UE's 
location and/or User CSG information has changed, the MME also includes the User Location Information IE 
and/or User CSG Information IE in this message. If ISR is activated the MME also includes the Serving Network 
IE in this message. If the UE Time Zone has changed compared to the last reported UE Time Zone then the 
MME shall include the UE Time Zone IE in this message. 

If a default EPS bearer is not accepted by the eNodeB, all the EPS bearers associated to that default bearer shall 
be treated as non-accepted bearers. The MME releases the non-accepted bearers by triggering the bearer release 
procedure as specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the 
Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME. 

9. If the RAT Type has changed compared to the last reported RAT Type or if the UE's Location and/or Info lEs 
and/or UE Time Zone are present in step 8, the Serving GW shall send the Modify Bearer Request message 
(RAT Type) per PDN connection to the PDN GW. User Location Information IE and/or User CSG Information 
IE and/or Serving Network IE and/or UE Time Zone are also included if they are present in step 8. 

10. If dynamic PCC is deployed, the PDN GW interacts with the PCRF to get the PCC rule(s) according to the RAT 
Type by means of a PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6]. If 
dynamic PCC is not deployed, the PDN GW may apply local QoS policy. 
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1 1 . The PDN GW sends the Modify Bearer Response to the Serving GW. 

12. The Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) to 
the MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving 
GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If the 
Serving GW cannot serve the MME Request in the Modify Access Bearers Request message without S5/S8 
signalling or without corresponding Gxc signalling when PMIP is used over the S5/S8 interface, it shall respond 
to the MME with indicating that the modifications are not limited to S 1-U bearers, and the MME shall repeat its 
request using a Modify Bearer Request message per PDN connection. 

5.3.4.2 Handling of abnormal conditions in UE triggered Service Request 

Under certain conditions, the current UE triggered Service Request procedure can cause unnecessary Downlink Packet 
Notification messages which increase the load of the MME. 

This can occur when uplink data sent in step 6 causes a response on the downlink which arrives at the Serving GW 
before the Update Bearer Request message, step 8. This data cannot be forwarded from the Serving GW to the eNodeB 
and hence it triggers a Downlink Data Notification message. 

If the MME receives a Downlink Data Notification after step 2 and before step 9, the MME shall not send S 1 interface 
paging messages. However, across all the UEs on that MME, the MME shall monitor the rate at which these events 
occur. If the rate becomes significant (as configured by the operator) and the MME's load exceeds an operator 
configured value, the MME shall indicate "Delay Downlink Packet Notification Request" with parameter D to the 
Serving Gateway, where D is the requested delay given as an integer multiple of 50 ms, or zero. The Serving GW then 
uses this delay in between receiving downlink data and sending the Downlink Data Notification message. 

NOTE 1 : A low rate of reception of Downlink Data Notifications between steps 2 and 9 should be considered a 

normal circumstance, e.g. due to the chance that a UE Terminating call/session is initiated at roughly the 
same time as the UE triggered Service Request procedure. 

NOTE 2: It is recommended that this rate is determined over 60 second periods. 

The MME shall use the step 8 Modify Access Bearers Request or Modify Bearer Request of the UE initiated Service 
Request procedure to indicate "Delay Downlink Packet Notification Request" to the Serving GW. 

To determine the amount of delay requested by a given MME, the Serving GW either uses the last Modify Access 
Bearers Request or Modify Bearer Request message which is part of a Service Request procedure, or, just uses one of 
the Service Request procedure's Modify Access Bearers Request or Modify Bearer Request messages received within 
the preceding 30 seconds. The latter mode of operation shall be taken into account when implementing the MME. 

The MME is responsible for setting the value of D. The exact algorithm for setting the value is implementation 
dependent, two examples are given below to serve as a guideline: 

EXAMPLE 1 : The MME adaptively increases the value of D when the rate of unnecessary Downlink Data 

Notifications is too high; and correspondingly it decreases the value when the rate is not too high. 

EXAMPLE 2: When unnecessary Downlink Data Notifications arrive, the MME measures the average time from 
the reception of the unnecessary Downlink Data Notification to the reception of the Modify 
Access Bearers Request or Modify Bearer Response from the Serving GW in the same UE 
triggered Service Request Procedure. The value of D is calculated from this average, by adding a 
safety margin. 

Normally, upon receipt of a downlink data packet for which there is no DL-TEID of the S 1 user plane tunnel, the S-GW 
shall send the Downlink Data Notification message to the MME without delay. 

If the S-GW determines from the last Modify Access Bearers Request or Modify Bearer Request message which is part 
of a Service Request procedure that a given MME request delaying of the Downlink Packet Notification by a delay of 
D, it shall (only for UEs of that MME) buffer the Downlink Data for a period D. If the DL-TEID and eNodeB address 
for the UE is received before the expiry of the timer, the timer shall be cancelled and the Network triggered Service 
Request procedure is finished without sending the Downlink Data Notification message to the MME, i.e. DL data are 
sent to the UE. Otherwise the Downlink Data Notification message is sent to the MME when the timer expires. 
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NOTE 3: The above procedure and indicated time values are intended to ensure that the procedure is "stable"; 

avoids RAN impacts; and, that the negative impacts of shortening the DRX interval on UE battery life are 
avoided. 



5.3.4.3 
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Figure 5.3.4.3-1 : Network triggered Service Request procedure 

If the MME needs to signal with the UE that is in ECM-IDLE state, e.g. to perform the MME/HSS-initiated detach 
procedure for the ECM-IDLE mode UE or the S-GW receives control signalling (e.g. Create Bearer Request or Update 
Bearer Request), the MME starts network triggered service request procedure from step 3a in the Network Triggered 
Service request procedure. 

If ISR is activated, when the Serving GW receives a Create Bearer Request or Update Bearer Request for a UE, and the 
S-GW does not have a downlink Sl-U and the SGSN has notified the Serving GW that the UE has moved to PMM- 
IDLE or STANDBY state, the Serving GW buffers signalling messages and sends a Downlink Data Notification to 
trigger the MME and SGSN to page the UE. If the Serving GW, while waiting for the user plane to be established, is 
triggered to send a second Downlink Data Notification with higher priority (i.e. ARP) than the first Downlink Data 
Notification was sent with, the Serving GW sends a new Downlink Data Notification message indicating the higher 
priority to the MME. If the Serving GW receives additional downlink signalling messages for a bearer with same or 
lower priority than the first Downlink Data Notification was sent for or ifthe Serving GW has sent the second Downlink 
Data Notification message indicating the higher priority and receives additional downlink signalling messages for this 
UE, the Serving GW buffers these downlink signalling messages and does not send a new Downlink Data Notification. 
The S-GW will be notified about the current RAT type based on the UE triggered service request procedure. The S-GW 
will go on executing the dedicated bearer activation or dedicated bearer modification procedure, i.e. send the 
corresponding buffered signalling to MME or SGSN which UE resides in now and inform the current RAT type to the 
PDN GW if the RAT type has been changed compared to the last reported RAT Type. If dynamic PCC is deployed, the 
current RAT type information shall also be conveyed from the PDN GW to the PCRF. If the PCRF response leads to an 
EPS bearer modification the PDN GW should initiate a bearer update procedure as specified in clause 5.4.2.1 below. 

When the Serving GW sends a Downlink Data Notification, it shall include both EPS Bearer ID and ARP. If the 
Downlink Data Notification is triggered by the arrival of downlink data packets at the Serving GW, the Serving GW 
shall include the EPS Bearer ID and ARP associated with the bearer on which the downlink data packet was received. If 
the Downlink Data Notification is triggered by the arrival of control signalling, the Serving GW shall include the EPS 
Bearer ID and ARP if present in the control signalling. If the ARP is not present in the control signalling, the Serving 
GW shall include the ARP in the stored EPS bearer context. 

If a LIPA PDN connection exists, when the L-GW receives the downlink data for a UE that is in ECM-IDLE state, the 
L-GW sends the first downlink user packet to Serving GW and buffers all other downlink user packets. The Serving 
GW will trigger the MME to page the UE. 
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1. When the Serving GW receives a downlink data packet for a UE known as not user plane connected (i.e. the 
S-GW context data indicates no downlink user plane TEID), it buffers the downlink data packet and identifies 
which MME or SGSN is serving that UE. 

If that MME has requested the Serving GW to throttle downlink low priority traffic and if the downlink data 
packet is received on a low priority bearer to be throttled (see clause 4.3.7.4. la), the SGW drops the downlink 
data. The steps below are not executed. 

If that MME has requested the S-GW to delay sending the Downlink Data Notification (see clause 5.3.4.2 on 
"Handling of abnormal conditions in UE triggered Service Request"), the Serving GW buffers the downlink data 
and waits until the timer expires before continuing with step 2. If the DL-TEID and eNodeB address for that UE 
is received before the expiry of the timer, the timer shall be cancelled and the Network triggered Service Request 
procedure is finished without executing the steps below, i.e. DL data are sent to the UE. 

If the Serving GW receives additional downlink data packets for this UE before the expiry of the timer, the 
Serving GW does not restart this timer. 

2. The Serving GW sends a Downlink Data Notification message to the MME and SGSN nodes for which it has 
control plane connectivity for the given UE. The ARP and EPS Bearer ID are always set in Downlink Data 
Notification. The MME and SGSN respond to the S-GW with a Downlink Data Notification Ack message. The 
priority indicator, i.e. ARP is derived from the bearer triggering the Downlink Data Notification. 

NOTE 1 : The ARP and EPS Bearer ID are sent to the SGSN as well as MME, but the usage of these parameters at 
SGSN is not specified in this release of the specification. 

If the Serving GW, while waiting for the user plane to be established, is triggered to send a second Downlink 
Data Notification for a bearer with higher priority (i.e. ARP) than the first Downlink Data Notification was sent 
for, the SGW sends a new Downlink Data Notification message indicating the higher priority to the MME. If the 
Serving GW receives additional downlink data packets for a bearer with same or lower priority than the first 
Downlink Data Notification was sent for or if the Serving GW has sent the second Downlink Data Notification 
message indicating the higher priority and receives additional downlink data packets for this UE, the Serving 
GW buffers these downlink data packets and the does not send a new Downlink Data Notification. 

3a. If the UE is registered in the MME, the MME sends a Paging message (NAS ID for paging, TAI(s), UE identity 
based DRX index. Paging DRX length, list of CSG IDs for paging. Paging Priority indication) to each eNodeB 
belonging to the tracking area(s) in which the UE is registered. The step is described in detail in TS 36.300 [5] 
and TS 36.413 [36]. Steps 3-4 are omitted if the MME already has a signalling connection over Sl-MME 
towards the UE. Paging priority indication is included only if MME receives a Downlink Data Notification with 
ARP associated with MPS. The ARP value for MPS is configured by operator policy. If the eNodeB during a 
congestion situation receives the Paging message with paging priority indication, eNodeB may perform the 
paging procedure with priority according to the indication. 

If the MME, while waiting for a UE response to the Paging Request message sent without priority indication, 
receives an Update Bearer Request, Create Bearer Request or Downlink Data Notification, any of which 
indicates a priority associated with MPS service, the MME shall resend the paging message with paging priority. 

When the MME is configured to support paging optimisation in the CN, the MME should avoid sending Paging 
messages to those eNodeB(s) with CSG cells for which the UE does not have a CSG subscription. When the 
MME is configured to support paging optimisation in the HeNB Subsystem, the list of CSG IDs for paging is 
included in the Paging message. For paging optimisation, the CSG IDs of expired CSG subscriptions and valid 
CSG subscriptions are both included in the list. If the UE has emergency bearer service the MME shall not 
perform the paging optimization. Paging optimization is described in clause 4.3.13. 

NOTE 2: An expired CSG subscription indicates that the UE is not allowed service in the CSG. However, since the 
removal of the CSG from the UE is pending, it is possible the UE will camp on that CSG and therefore 
the UE is still paged for the CSG. 

NOTE 3: The eNodeB reports to the MME the CSG ID supported. For More detail of this procedure refer to 
TS 36.413 [36]. 

The MME may use the EPS bearer context information identified by EPS bearer ID received in Downlink Data 
Notification message in order to control the paging based on operator policy, such as: 

- paging retransmission strategies; 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 10 119 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

determining whether to send the Paging message to the eNodeBs during certain MME high load conditions; 
paging optimisations for traffic arriving on the PDN connection used for Local IP Access without mobility. 

NOTE 4: The Paging priority in the Paging message is set based on ARP received in Downlink Data Notification 

message. 

3b. If the UE is registered in the SGSN, the SGSN sends paging messages to RNC/BSS, which is described in detail 
in TS 23.060 [7]. 

4a. If eNodeBs receive paging messages from the MME, the UE is paged by the eNodeBs. The step is described in 
detail in TS 36.300 [5] and TS 36.304 [34]. 

4b. If RNC/BSS nodes receive paging messages from the SGSN the UE is paged by the RNSC/BSS, which is 
described in detail in TS 23.060 [7]. 

5. When UE is in the ECM-IDLE state, upon reception of paging indication in E-UTRAN access, the UE initiates 
the UE triggered Service Request procedure (clause 5.3.4.1). If the MME already has a signalling connection 
over SI -MME towards the UE, then the messages sequence performed start from the step when MME 
establishes the bearer(s). 

Upon reception of paging indication in UTRAN or GERAN access, the MS shall respond in respective access as 
specified TS 24.008 [47] and the SGSN shall notify the S-GW. 

The MME and/or SGSN supervises the paging procedure with a timer. If the MME and/or SGSN receives no 
response from the UE to the Paging Request message, it may repeat the paging. The repetition strategy is 
operator dependent. In the case of paging optimization described in clause 4.3.13, the paging optimization may 
be disabled. 

If the MME and/or SGSN receives no response from the UE after this paging repetition procedure, it shall use 
the Downlink Data Notification Reject message to notify the Serving GW about the paging failure. In that case, 
if ISR is not activated, the Serving GW deletes the buffered packet(s). If ISR is activated and the Serving GW 
receives paging failure from both SGSN and MME, the Serving GW deletes the buffered packet(s) or rejects the 
control signalling which triggers the Service Request procedure. 

6a. If ISR is activated and paging response is received in E-UTRAN access the Serving GW sends a "Stop Paging" 
message to the SGSN. 

6b. If ISR is activated and paging response is received in UTRAN or GERAN access the Serving GW sends a "Stop 
Paging" message to the MME. 

The Serving GW transmits downlink data towards the UE via the RAT which performed the Service Request procedure. 

For a LIPA PDN connection, after the UE enters connected mode, the packets buffered in the L-GW are forwarded to 
the HeNB on the direct path. If the UE enters connected mode at a different cell than the one where the L-GW is 
colocated, the MME shall deactivate the LIPA PDN connection as defined in clause 5.3.4.1 step 2. 

If the network triggered service request fails due to no response from the UE, then MME and/or SGSN may based on 
operator policy initiate the Dedicated Bearer Deactivation procedure for preserved GBR bearers. For details, see 
clause 5.4.4.2 for MME and TS 23.060 [7] for SGSN. 



5.3.5 S1 release procedure 



This procedure is used to release the logical Sl-AP signalling connection (over SI -MME) and all SI bearers (in Sl-U) 
for a UE. The procedure will move the UE from ECM -CONNECTED to ECM-IDLE in both the UE and MME, and all 
UE related context information is deleted in the eNodeB. 

The initiation of S 1 Release procedure is either: 

eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC 
signalling Integrity Check Failure, Release due to UE generated signalling connection release, CS Fallback 
triggered, Inter-RAT Redirection, etc. as defined in TS 36.413 [36]; or 

MME-initiated with cause e.g. authentication failure, detach, not allowed CSG cell (e.g. the CSG ID of the 
currently used CSG cell expires or is removed from the CSG subscription data), etc. 
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In case of eNodeB Failure, MME may based on operator policy either preserve all bearers or initiate the Dedicated 
Bearer Deactivation procedure for GBR bearers. See clause 5.4.4.2. 

Both eNodeB-initiated and MME-initiated SI release procedures are shown in Figure 5.3.5-1. 



UE 



eNodeB 



5. RRC Connection 



MME 



1. S1-AP: S1 UE Context Release Request 



► 



Serving GW 



2. Release Access ffiearers Request 

► 

3. Release Access Bearers Response 



4. S1-AP: S1 UE CDntext Release Command 



Release 



6. S1-AP; S1 UE Context Release Complete 



Figure 5.3.5-1 : SI Release Procedure 

1 . If the eNodeB detects a need to release the UE's signalling connection and all radio bearers for the UE, the 
eNodeB sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates the reason for 
the release (e.g. O&M intervention, unspecified failure, user inactivity, repeated integrity checking failure, or 
release due to UE generated signalling connection release). 

NOTE 1: Step 1 is only performed when the eNodeB-initiated SI release procedure is considered. Step 1 is not 
performed and the procedure starts with Step 2 when the MME-initiated S 1 release procedure is 
considered. 

2. The MME sends a Release Access Bearers Request message to the S-GW that requests the release of all S 1-U 
bearers for the UE. This message is triggered either by an SI Release Request message from the eNodeB, or by 
another MME event. 

3. The S-GW releases all eNodeB related information (address and TEIDs) for the UE and responds with a Release 
Access Bearers Response message to the MME. Other elements of the UE's S-GW context are not affected. The 
S-GW retains the Sl-U configuration that the S-GW allocated for the UE's bearers. The S-GW starts buffering 
downlink packets received for the UE and initiating the "Network Triggered Service Request" procedure, 
described in clause 5.3.4.3, if downlink packets arrive for the UE. 

4. The MME releases SI by sending the SI UE Context Release Command (Cause) message to the eNodeB. 

5. If the RRC connection is not already released, the eNodeB sends a RRC Connection Release message to the UE 
in Acknowledged Mode. Once the message is acknowledged by the UE, the eNodeB deletes the UE's context. 

6. The eNodeB confirms the SI Release by returning an SI UE Context Release Complete message to the MME. 
With this, the signalling connection between the MME and the eNodeB for that UE is released. This step shall be 
performed promptly after step 4, e.g. it shall not be delayed in situations where the UE does not acknowledge the 
RRC Connection Release. 

The MME deletes any eNodeB related information ("eNodeB Address in Use for Sl-MME" and "eNB UE SlAP 
ID") from the UE's MME context, but, retains the rest of the UE's MME context including the S-GW's Sl-U 
configuration information (address and TEIDs). All non-GBR EPS bearers established for the UE are preserved 
in the MME and in the Serving GW. 

If the cause of S 1 release is because of User I inactivity, Inter-RAT Redirection, the MME shall preserve the 
GBR bearers. If the cause of S 1 release is because of CS Fallback triggered, further details about bearer handling 
are described in TS 23.272 [58]. Otherwise, e.g. Radio Connection With UE Lost, the MME shall trigger the 
MME Initiated Dedicated Bearer Deactivation procedure (clause 5.4.4.2) for the GBR bearer(s) of the UE after 
the S 1 Release procedure is completed. 
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NOTE 2: EPC does not support the GPRS preservation feature with setting the MBR for GBR bearers to zero. 

If LIPA is active for a PDN connection, the HeNB informs the collocated L-GW by internal signalling to 
releases the direct user plane path to the HeNB. After the direct user plane path is released, if downlink packets 
arrive for the UE, the L-GW forwards the first packet on the S5 tunnel to the S-GW to initiate the "Network 
Triggered Service Request" procedure, as described in clause 5.3.4.3. 

5.3.6 Void 



5.3.7 GUTI Reallocation procedure 

The MME may initiate the GUTI Reallocation procedure to reallocate the GUTI and/or TAI list at any time when a 
signalling association is established between UE and MME. The GUTI Reallocation procedure allocates a new GUTI 
and/or a new TAI list to the UE. The GUTI and/or the TAI list may also be reallocated by the Attach or the Tracking 
Area Update procedures. 

The GUTI Reallocation procedure is illustrated in Figure 5.3.7-1. 




Figure 5.3.7-1 : GUTI Reallocation Procedure 

1. The MME sends GUTI Reallocation Command (GUTI, TAI list) to the UE. 

2. The UE returns GUTI Reallocation Complete message to the MME. 

5.3.8 Detach procedure 
5.3.8.1 General 

The Detach procedure allows: 

the UE to inform the network that it does not want to access the EPS any longer, and 

the network to inform the UE that it does not have access to the EPS any longer. 
The UE is detached either explicitly or implicitly: 

Explicit detach: The network or the UE explicitly requests detach and signal with each other. 

Implicit detach: The network detaches the UE, without notifying the UE. This is typically the case when the 
network presumes that it is not able to communicate with the UE, e.g. due to radio conditions. 

Four detach procedures are provided when the UE accesses the EPS through E-UTRAN. The first detach procedure is 
UE-initiated detach procedure and other detach procedures are network-initiated detach procedure: 

UE-Initiated Detach Procedure. In the ISR activated case the UE initiated detach is split into two sub procedures, 
one for UE camping on E-UTRAN and one for UE camping on GERAN/UTRAN; 
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MME-Initiated Detach Procedure; 

SGSN-Initiated Detach procedure with ISR activated; 
- HSS-Initiated Detach Procedure. 
NOTE 1: The MME and the UE may enter EMM-DEREGISTERED state without the above procedures. 

5.3.8.2 UE-initiated Detach procedure 

The Detach procedure when initiated by the UE is described in clauses 5.3.8.2.1 and 5.3.8.2.2. 

5.3.8.2.1 UE-initiated Detach procedure for E-UTRAN 

Figure 5.3.8.2-1 shows the case when UE camps on E-UTRAN and Detach Request is sent to MME. 
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Figure 5.3.8.2-1 : UE-lnitiated Detach Procedure - UE camping on E-UTRAN 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 6, 7 and 8 concern GTP 
based S5/S8 

1. The UE sends NAS message Detach Request (GUTI, Switch Off) to the MME. This NAS message is used to 
trigger the establishment of the SI connection if the UE was in ECM-IDLE mode. Switch Off indicates whether 
detach is due to a switch off situation or not. The eNodeB forwards this NAS message to the MME along with 
the TAIh-ECGI of the cell which the UE is using. 

If the MME receives a Detach Request via a CSG cell with Switch Off parameter indicating that detach is not 
due to a switch off situation, and the CSG subscription for this CSG ID is absent or expired, the MME shall 
trigger a MME-initiated Detach procedure as specified in clause 5.3.8.3. 

NOTE 2: Security procedures may be invoked if the NAS message is used to establish the S 1 connection. 

NOTE 3: For emergency attached UEs that were not successfully authenticated, security procedures are not 
performed. 

2. The active EPS Bearers in the Serving GW regarding this particular UE are deactivated by the MME sending 
Delete Session Request (LB I) per PDN connection to the Serving GW. If ISR is activated, then the Serving GW 
shall not release the Control Plane TEID allocated for MME/SGSN until it receives the Delete Session Request 
message in step 5. If the PDN GW requested UE's location info, the MME also includes the User Location 
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Information IE in this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in 
this message. 

3. When the S-GW receives the first Delete Session Request message from the MME or SGSN in ISR activated 
state, the Serving GW deactivates ISR, releases the related EPS Bearer context information and responds with 
Delete Session Response (Cause). 

When the S-GW receives the Delete Session Request message from the MME or SGSN in ISR deactivated state, 
the Serving GW releases the related EPS Bearer context information and jumps to step 6 by sending a Delete 
Session Request (LB I) message per PDN connection to the PDN GW. After step 7 the Serving GW responds 
back to the MME/SGSN with the Delete Session Response (Cause) message. 

4. If ISR is activated, MME sends Detach Indication (Cause) message to the associated SGSN. The Cause indicates 
complete detach. 

5. The active PDP contexts in the Serving GW regarding this particular UE are deactivated by the SGSN sending 
Delete Session Request (LB I) per PDN connection to the Serving GW. If the PDN GW requested UE's location 
info, the SGSN also includes the User Location Information IE in this message. If the UE Time Zone has 
changed, the SGSN includes the UE Time Zone IE in this message. 

6. If ISR is activated. Serving GW deactivates ISR. If ISR is not activated in the Serving GW, the Serving GW 
sends Delete Session Request (LB I) per PDN connection to the PDN GW. If ISR is not activated, this step shall 
be triggered by step 2. This message indicates that all bearers belonging to that PDN connection shall be 
released. If the MME and/or SGSN sends UE's Location Information and/or UE Time Zone in step 2 and/or 
step 5, the S-GW includes the User Location Information and/or UE Time Zone with the least age in this 
message. 

7. The PDN GW acknowledges with Delete Session Response (Cause). 

8. The PDN GW employs a PCEF initiated IP-CAN Session Termination Procedure as defined in TS 23.203 [6] 
with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network. 

9. The Serving GW acknowledges with Delete Session Response (Cause). 

10. The SGSN sends Detach Acknowledge message to the MME. 

11 . If Switch Off indicates that detach is not due to a switch off situation, the MME sends a Detach Accept to the 
UE. 

12. The MME releases the Sl-MME signalling connection for the UE by sending SI Release Command to the 
eNodeB with Cause set to Detach. The details of this step are covered in the "SI Release Procedure", as 
described in clause 5.3.5. 

5.3.8.2.2 UE-initiated Detach procedure for GERAN/UTRAN with ISR activated 

Figure 5.3.8.2-2 shows the case when UE with ISR Activated camps on GERAN/UTRAN and Detach Request is sent to 
SGSN. Refer to clause 6.6.1 of TS 23.060 [7] for the UE-initiated Detach procedure when ISR is not activated. 
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Figure 5.3.8.2-2: UE-lnitiated Detach Procedure - UE camping on GERAN/UTRAN, ISR activated 

1. The UE sends NAS message Detach Request (Detach Type, P-TMSI, P-TMSI-Signature, Switch Off) to the 
SGSN. Detach Type indicates which type of detach is to be performed, i.e. GPRS Detach only, IMSI Detach 
only or combined GPRS and IMSI Detach. Switch Off indicates whether detach is due to a switch off situation 
or not. The Detach Request message includes P-TMSI and P-TMSI Signature. P-TMSI Signature is used to 
check the validity of the Detach Request message. If P-TMSI Signature is not valid or is not included, the 
authentication procedure should be performed. 

If the SGSN receives a Detach Request via a CSG cell with Switch Off parameter indicating that detach is not 
due to a switch off situation, and the CSG subscription for this CSG ID is absent or expired, the SGSN shall 
trigger a SGSN-initiated Detach procedure as specified in clause 5.3.8.3A. 

2. The active EPS Bearers in the Serving GW regarding this particular UE are deactivated by the SGSN sending 
Delete Session Request (LBI) per PDN connection to the Serving GW. Because ISR is activated, then the 
Serving GW shall not release the Control Plan TEID allocated for MME/SGSN until it receives the Delete 
Session Request message in step 5. If the PDN GW requested UE's location info, the SGSN also includes the 
User Location Information IE in this message. If the UE Time Zone has changed, the SGSN includes the UE 
Time Zone IE in this message. 

3. Because the Serving GW receives this message in ISR activated state, the Serving GW deactivates ISR and 
acknowledges with Delete Session Response (Cause). 

4. Because ISR is activated, the SGSN sends Detach Notification (Cause) message to the associated MME. Cause 
indicates complete detach. 

5. The active PDP contexts in the Serving GW regarding this particular UE are deactivated by the MME sending 
Delete Session Request (LBI) per PDN connection to the Serving GW. If the PDN GW requested UE's location 
info, the MME also includes the User Location Information IE in this message. If the UE Time Zone has 
changed, the MME includes the UE Time Zone IE in this message. 

6. Serving GW deactivates ISR and sends Delete Session Request (LBI) per PDN connection to the PDN GW. If 
ISR is not activated, this step shall be triggered by step 2. This message indicates that all bearers belonging to 
that PDN connection shall be released. If the MME and/or SGSN sends UE's Location Information and/or UE 
Time Zone in step 2 and/or step 5, the S-GW includes the User Location Information and/or UE Time Zone with 
the least age in this message. 

7. The PDN GW acknowledges with Delete Session Response (Cause). 
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8. The PDN GW employs a PCEF initiated IP CAN Session Termination Procedure as defined in TS 23.203 [6] 
with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network. 

9. The Serving GW acknowledges with Delete Session Response (Cause). 

10. The MME sends Detach Acknowledge message to the SGSN. 

11 . If Switch Off indicates that detach is not due to a switch off situation, the SGSN sends a Detach Accept to the 
UE. 

12. If the MS was GPRS detached, then the 3G SGSN releases the PS signalling connection. 

5.3.8.3 MME-initiated Detach procedure 

The MME-Initiated Detach procedure when initiated by the MME is illustrated in Figure 5.3.8.3-1. 

This procedure may be also used as part of the SIPTO function when the MME determines that GW relocation is 
desirable for all PDN connection(s). The MME initiates the "explicit detach with reattach required" procedure and the 
UE should then re-establish those PDN connections for the same APN(s). 
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Figure 5.3.8.3-1 : MME-Initiated Detach Procedure 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4 and 5 concern GTP 
based S5/S8. 

NOTE 2: Procedure steps (B) are used by the procedure steps (E) in clause 5.3.2.1. 

1. The MME initiated detach procedure is either explicit (e.g. by O&M intervention) or implicit. The MME may 
implicitly detach a UE, if it has not had communication with UE for a long period of time. The MME does not 
send the Detach Request (Detach Type) message to the UE for implicit detach. The implicit detach is local to the 
MME, i.e. an SGSN registration will not be detached. If the UE is in ECM-CONNNECTED state the MME may 
explicitly detach the UE by sending a Detach Request message to the UE. The Detach Type may be set to re- 
attach in which case the UE should re-attach at the end of the detach process. If the UE is in ECM-IDLE state the 
MME pages the UE. 

For emergency attached UEs, MME initiated implicit detach procedures are based on an inactivity timeout 
specific to emergency. 

If this Detach procedure is due to the UE's Detach Request via a CSG cell which the UE is not allowed to access, 
i.e. the CSG subscription for this CSG ID is absent or expired, the MME shall send a Detach Request to UE with 
an appropriate cause indicating the UE is not allowed to access this CSG. 
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2. Any EPS Bearer Context information in the Serving GW regarding this particular UE and related to the MME 
are deactivated by the MME sending Delete Session Request (LB I) message per PDN connection to the Serving 
GW. If the PDN GW requested UE's location info, the MME also includes the User Location Information IE in 
this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. 

3. When the S-GW receives the first Delete Session Request message from the MME or SGSN in ISR activated 
state, the Serving GW deactivates ISR, releases the related EPS Bearer context information and responds with 
Delete Session Response (Cause). 

When the S-GW receives the Delete Session Request message from the MME or SGSN in ISR deactivated state, 
the Serving GW releases the related EPS Bearer context information and jumps to step 6 by sending a Delete 
Session Request (LBI) message to the PDN GW. After step 7 the Serving GW responds back to the MME/SGSN 
with the Delete Session Response (Cause) message. 

4. If ISR is activated, MME sends Detach Notification (Cause) message to the associated SGSN. The cause 
indicates whether it is a local or complete detach. 

5. If cause indicates complete detach then the SGSN sends a Delete Session Request (LBI) message per PDN 
connection to the Serving GW. If Cause indicates local detach then SGSN deactivates ISR and steps 5 to 9 shall 
be skipped. If the PDN GW requested UE's location info, the SGSN also includes the User Location Information 
IE in this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. 

6. If ISR is activated. Serving GW deactivates ISR. 

If ISR is not activated and the Serving GW received one or several Delete Bearer Request message(s) from 
SGSN in step 2, the Serving GW sends a Delete Session Request (LBI) message for each associated PDN 
connection to the PDN GW. This message indicates that all bearers belonging to that PDN connection shall be 
released. 

If the MME and/or SGSN send(s) UE's Location Information and/or UE Time Zone in step 2 and/or Step 5, the 
S-GW includes the User Location Information and/or UE Time Zone with the least age in this message. 

7. The PDN GW acknowledges with Delete Session Response (Cause) message. 

8. The PDN GW employs an IP-CAN Session Termination procedure as defined in TS 23.203 [6] with the PCRF to 
indicate to the PCRF that the EPS Bearer(s) are released if a PCRF is configured. 

9. The Serving GW acknowledges with Delete Session Response (Cause) message. 

10. The SGSN sends Detach Acknowledge message to the MME. 

n . If the UE receives the Detach Request message from the MME in the step 1 , the UE sends a Detach Accept 
message to the MME any time after step 1. The eNodeB forwards this NAS message to the MME along with the 
TAlH-ECGI of the cell which the UE is using. 

If the UE receives Detach Request from the MME via a CSG cell with the cause indicating the UE is not allowed 
to access this CSG, the UE shall remove this CSG ID from its Allowed CSG list, if present. 

12. After receiving the Detach Accept message. Delete Session Response and, if appropriate. Detach Acknowledge 
message, the MME releases the SI -MME signalling connection for the UE by sending an SI Release Command 
(Cause) message to the eNodeB. The details of this step are covered in the "SI Release Procedure", as described 
in clause 5.3.5 by step 4 to step 6. If the Detach Type requests the UE to make a new attach, the UE reattaches 
after the RRC Connection Release is completed. 

5.3.8.3A SGSN-initiated Detach procedure with ISR activated 

The SGSN-Initiated Detach procedure with ISR activated is illustrated in Figure 5.3.8.3A-L Refer to clause 6.6.2.1 of 
TS 23.060 [7] for the SGSN-initiated Detach procedure when ISR is not activated. 
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Figure 5.3.8.3A-1 : SGSN-lnitiated Detach Procedure with ISR activated 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4 and 5 concern GTP 
based S5/S8. 

1. The SGSN initiated detach procedure is either expHcit (e.g. by O&M intervention) or impHcit. The SGSN may 
impHcitly detach a UE, if it has not had communication with UE for a long period of time. The SGSN does not 
send the Detach Request (Detach Type) message to the UE for impHcit detach. The impHcit detach is local to the 
SGSN, i.e. an MME registration will not be detached. If the UE is in PMM-CONNNECTED state the SGSN 
may explicitly detach the UE by sending a Detach Request message to the UE. The Detach Type may be set to 
re-attach in which case the UE should re-attach at the end of the detach process. If the UE is in PMM-IDLE state 
the SGSN pages the UE. 

If this Detach procedure is due to the UE's Detach Request via a CSG cell which the UE is not allowed to access, 
i.e. the CSG subscription for this CSG ID is absent or expired, the SGSN shall send a Detach Request to UE with 
an appropriate cause indicating the UE is not allowed to access this CSG. 

2. Any EPS Bearer Context information in the Serving GW regarding this particular UE and related to the SGSN is 
deactivated by the SGSN sending Delete Session Request (LBI) message per PDN connection to the Serving 
GW. If the PDN GW requested UE's location info, the SGSN also includes the User Location Information IE in 
this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. 

3. Because the Serving GW receives this message in ISR activated state, the Serving GW deactivates ISR, releases 
the SGSN related EPS Bearer context information and acknowledges with Delete Session Response (Cause). 

4. Because ISR is activated, the SGSN sends Detach Notification (Cause) message to the associated MME. The 
cause indicates whether it is a local or complete detach. 

5. If cause indicates complete detach then the MME sends a Delete Session Request (LBI) message per PDN 
connection to the Serving GW. If Cause indicates local detach then MME deactivates ISR and steps 5 to 9 shall 
be skipped. If the PDN GW requested UE's location info, the MME also includes the User Location Information 
IE in this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. 

6. The Serving GW sends a Delete Session Request (LBI) message per PDN connection to the PDN GW. This 
message indicates that all bearers belonging to that PDN connection shall be released. If the MME and/or SGSN 
sends UE's Location Information and/or UE Time Zone in step 2 and/or step 5, the S-GW includes the User 
Location Information and/or UE Time Zone with the least age in this message. 

7. The PDN GW acknowledges with Delete Session Response (Cause) message. 
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8. The PDN GW employs an IP CAN Session Termination procedure as defined in TS 23.203 [6] with the PCRF to 
indicate to the PCRF that the EPS Bearer(s) are released if a PCRF is configured. 

9. The Serving GW acknowledges with Delete Session Response (Cause) message. 

10. The MME sends Detach Acknowledge message to the SGSN. 

1 1 . If the UE receives the Detach Request message from the SGSN in the step 1 , the UE sends a Detach Accept 
message to the SGSN any time after step 1. 

If the UE receives Detach Request from the SGSN via a CSG cell with the cause indicating the UE is not 
allowed to access this CSG, the UE shall remove this CSG ID from its Allowed CSG list, if present. 

12. After receiving the Detach Accept message, if Detach Type did not request the UE to make a new attach, then 
the 3G SGSN releases the PS signalling connection. 



5.3.8.4 



HSS-initiated Detach procedure 



The HSS-Initiated Detach procedure is initiated by the HSS. The HSS uses this procedure for operator-determined 
purposes to request the removal of a subscriber's MM and EPS bearer at the MME and also at the SGSN if both an 
MME and an SGSN are registered in the HSS. 

For UEs with emergency EPS bearers, the MME/SGSN shall not initiate detach procedure. Instead the MME/SGSN 
shall deactivate all the non emergency PDN connection. 

For subscription change, e.g. RAT restrictions to disallow one of the RATs, the Insert Subscription Data procedure shall 
be used towards the MME, and also towards the SGSN if both an MME and an SGSN are registered in the HSS. 

This procedure is not applied if a Cancel Location is sent to the MME or the SGSN with a cause other than Subscription 
Withdrawn. 

The HSS-Initiated Detach Procedure is illustrated in Figure 5.3.8.4-1. 
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Figure 5.3.8.4-1 : HSS-Initiated Detach Procedure 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 4, 5 and 6 concern GTP 
based S5/S8. 

NOTE 2: Procedure steps (B) are used by the procedure steps (F) in clause 5.3.2. 1. 
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NOTE 3: The steps below apply for an S4-SGSN. For Gn/Gp SGSN, the procedure specified in clause 6.6.2.2. of 
TS 23.060 [7] applies for the SGSN. 

1. If the HSS wants to request the immediate deletion of a subscriber's MM contexts and EPS Bearers, the HSS 
shall send a Cancel Location (IMSI, Cancellation Type) message with Cancellation Type set to Subscription 
Withdrawn to the registered MME and also to the SGSN if an SGSN is also registered. 

2. If Cancellation Type is Subscription Withdrawn, the MME/SGSN which has an active UE context informs the 
UE which is in ECM-CONNECTED state, that it has been detached, by sending Detach Request message to the 
UE. If the UE is in ECM-IDLE state the MME pages the UE. 

NOTE 4: The UE will receive only one Detach Request message in the RAT where it currently camps on. 

3a. If the MME has an active UE context, the MME sends a Delete Session Request (LB I) message per PDN 
connection to the Serving GW to deactivate the EPS Bearer Context information in the Serving GW. 

3b. If the SGSN has an active UE context, the SGSN sends a Delete Session Request (LB I) per PDN connection to 
the Serving GW to deactivate the EPS Bearer Context information in the Serving GW. 

4. When the S-GW receives the first Delete Session Request message from the MME or SGSN in ISR activated 
state, the Serving GW deactivates ISR, releases the related EPS Bearer context information and responds with 
Delete Session Response in step 7. 

When the S-GW receives one or several Delete Session Request message(s) from the MME or SGSN in ISR 
deactivated state, the Serving GW releases the related EPS Bearer context information and sends a Delete 
Session Request (LBI) message for each associated PDN connection to the PDN GW. This message indicates 
that all bearers belonging to that PDN connection shall be released. 

5. The PDN GW acknowledges with Delete Session Response (Cause) message. 

6. The PDN GW employs a PCEF initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6] 
with the PCRF to indicate to the PCRF that the EPS bearer is released if a PCRF is configured. 

7. The Serving GW acknowledges with Delete Session Response (TEID) message. 

8. If the UE receives the Detach Request message from the MME/SGSN, the UE sends a Detach Accept message to 
the MME/SGSN any time after step 2. The message is sent either in E-UTRAN or GERAN/UTRAN access 
depending on which access the UE received the Detach Request. For the Detach Accept message from UE to 
MME the eNodeB forwards this NAS message to the MME along with the TAIh-ECGI of the cell which the UE 
is using. 

9. The MME/SGSN confirms the deletion of the MM contexts and the EPS Bearer(s) with a Cancel Location Ack 
(IMSI) message to the HSS. 

10a. After receiving the Detach Accept message, the MME releases the SI -MME signalling connection for the UE 
by sending S 1 Release Command (Cause) message to the eNodeB with Cause set to Detach. The details of this 
step are covered in the "SI Release Procedure", as described in clause 5.3.5. 

10b. After receiving the Detach Accept message, if Detach Type did not request the UE to make a new attach, 
then the 3G SGSN releases the PS signalling connection 

5.3.9 HSS User Profile management function procedure 

5.3.9.1 General 

The HSS user profile management function allows the HSS to update the HSS user profile stored in the MME. 
Whenever the HSS user profile is changed for a user in the HSS, and the changes affect the HSS user profile stored in 
the MME, the MME shall be informed about these changes by the means of the following procedure: 

Insert Subscriber Data procedure, used to add or modify the HSS user profile in the MME. 

5.3.9.2 Insert Subscriber Data procedure 

The Insert Subscriber Data procedure is illustrated in Figure 5.3.9.2-1. 
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Figure 5.3.9.2-1 : Insert Subscriber Data procedure 

1. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the MME. 

2. The MME updates the stored Subscription Data and acknowledges the Insert Subscriber Data message by 
returning an Insert Subscriber Data Ack (IMSI) message to the HSS. The update result should be contained in 
the Ack message. 

The MME initiates appropriate action according to the changed subscriber data (e.g. MME initiates detach if the 
UE is not allowed to roam in this network). For received PDN subscription contexts that have no related active 
PDN connection in the MME, no further action is required except storage in the MME. Otherwise if the 
subscribed QoS Profile has been modified and the UE is in ECM-CONNECTED state or in ECM-IDLE state 
when ISR is not activated, the HSS Initiated Subscribed QoS Modification procedure, as described in 
Figure 5.4.2.2-1, is invoked from step 2a. If the UE is in ECM-IDLE state and the ISR is activated, this 
procedure is invoked at the next ECM-IDLE to ECM-CONNECTED transition. If the UE is in ECM-IDLE state 
and the ISR is not activated and if the subscription change no longer allows the PDN connection, the MME 
initiated PDN disconnection procedure in clause 5.10.3 is used to delete the concerned PDN connection. 

If the UE is in ECM-CONNECTED state and connected via a CSG or hybrid cell, the MME shall check the 
received CSG subscription data. If the MME detects that the CSG membership to that cell has changed or 
expired, the MME initiates the procedure in clause 5.16. 



5.3.9.3 



Purge function 



The Purge function allows an MME to inform the HSS that it has deleted the subscription data and MM context of a 
detached MS. The MME may, as an implementation option, delete the subscription data and MM context of an UE 
immediately after the implicit or explicit detach of the UE. Alternatively the MME may keep for some time the 
subscription data and the MM context of the detached UE, so that the data can be reused at a later attach without 
accessing the HSS. 
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Figure 5.3.9.3-1 : Purge Procedure 

1 . After deleting the Subscription data and MM contexts of a detached UE, the MME sends Purge UE (IMSI) 
message to the HSS. 

2. The HSS sets the UE Purged for E-UTRAN flag and acknowledges with a Purge UE Ack message. 

5.3.10 Security Function 
5.3.10.1 General 

The security functions include: 
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The security functions include: 

Guards against unauthorised EPS service usage (authentication of the UE by the network and service request 
vaHdation). 

Provision of user identity confidentiality (temporary identification and ciphering). 

Provision of user data and signalling confidentiality (ciphering). 

Provision of origin authentication of signalling data (integrity protection). 

Authentication of the network by the UE. 

Security-related network functions for EPS are described in TS 33.401 [41]. 

5.3.1 0.2 Authentication and Key Agreement 

EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN, between the UE and 
MME. EPS AKA is specified in TS 33.401 [41]. 

5.3.1 0.3 User Identity Confidentiality 

An M-TMSI identifies a user between the UE and the MME. The relationship between M-TMSI and IMSl is known 
only in the UE and in the MME. 

5.3.1 0.4 User Data and Signalling Confidentiality 

There are two different levels of the security associations between the UE and the network. 

i) RRC and UP security association is between the UE and E-UTRAN. The RRC security associations protect the 
RRC signalling between the UE and E-UTRAN (integrity protection and ciphering). The UP security association 
is also between the UE and E-UTRAN and provide user plane encryption function. 

ii) NAS security association is between the UE and the MME. It provides integrity protection and encryption of 
NAS signalhng. 



5.3.10.4.1 



AS security mode command procedure 



The MME triggers the RRC level AS security mode command procedure by sending the needed security parameters to 
the eNodeB. This enables ciphering of the UP traffic and ciphering and integrity protection of the RRC signalling as 
described in TS 33.401 [41]. 



5.3.10.4.2 



NAS Security Mode Command procedure 



The MME uses the NAS Security Mode Command (SMC) procedure to establish a NAS security association between 
the UE and MME, in order to protect the further NAS signalling messages. This procedure is also used to make changes 
in the security association, e.g. to change the security algorithm. 
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Figure 5.3.10.4.2-1 : NAS Security IVIode Command Procedure 
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1 . The MME sends NAS Security Mode Command (Selected NAS algorithms, eKSI, ME Identity request, UE 
Security Capability) message to the UE. ME identity request may be included when NAS SMC is combined with 
ME Identity retrieval (see clause 5.3.10.5). 

2. The UE responds NAS with Security Mode Complete (NAS-MAC, ME Identity) message. The UE includes the 
ME Identity if it was requested in step 1 . 

NOTE: The NAS Security Mode Command procedure is typically executed as part of the Attach procedure (see 
clause 5.3.2.1) in advance of, or in combination with, executing the ME Identity Check procedure (see 
clause 5.3.10.5) and in the TAU procedure (see clauses 5.3.3.1 and 5.3.3.2). 

More details of the procedure are described in TS 33.401 [41]. 

5.3.1 0.5 ME identity checl^ procedure 

The Mobile Equipment Identity Check Procedure permits the operator(s) of the MME and/or the HSS and/or the 

PDN GW to check the Mobile Equipment's identity (e.g. to check that it has not been stolen, or, to verify that it does not 

have faults). 

The ME Identity can be checked by the MME passing it to an Equipment Identity Register (EIR) and then the MME 
analysing the response from the EIR in order to determine its subsequent actions (e.g. sending an Attach Reject if the 
EIR indicates that the Mobile Equipment is blacklisted). 

The ME identity check procedure is illustrated in Figure 5.3.10.5-1. 
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Figure 5.3.10.5-1 : Identity Check Procedure 

1 . The MME sends Identity Request (Identity Type) to the UE. The UE responds with Identity Response (Mobile 
Identity). 

2. If the MME is configured to check the IMEI against the EIR, it sends ME Identity Check (ME Identity, IMSI) to 
EIR. The EIR responds with ME Identity Check Ack (Result). 

NOTE: The Identity Check Procedure is typically executed as part of the Attach procedure (see clause 5.3.2.1). 

For roaming situations, in order to permit the HPLMN operator to check the ME Identity, the VPLMN shall obtain the 
ME identity at Initial Attach when Request Type does not indicate handover, and, at Tracking Area Update from 
UTRAN/GERAN if the old SGSN does not provide the ME Identity. In order to minimise signalling delays during these 
procedures, the MME should obtain the ME Identity in the NAS Security Mode Complete message during the EPC 
Authentication and Ciphering procedure as defined in clause 5.3.10.4.2. More details are described in TS 33.401 [41]. 

At Initial Attach when Request Type does not indicate handover, the MME includes the ME Identity in the Update 
Location message to the HSS. 

NOTE: The mechanisms by which the HSS and/or PDN GW check the ME Identity are not standardised in this 
release of the 3GPP specifications. 
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5.3.1 1 UE Reachability procedures 

5.3.11.1 General 

There are two procedures necessary for any service related entity that would need to be notified by the reachability of 
the UE at EPC NAS level: 

UE Reachability Notification Request procedure; and 

UE Activity Notification procedure. 

5.3.1 1 .2 UE Reachability Notification Request procedure 

The UE Reachability Notification Request procedure is illustrated in Figure 5.3. 1 1 .2-1 . 
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Figure 5.3.11.2-1: UE Reachability Notification Request Procedure 

1) If a service-related entity requests the HSS to provide an indication regarding UE reachability on EPS, the HSS 
stores the service-related entity and sets the URRP-MME parameter to indicate that such request is received. If 
the value of URRP-MME parameter has changed from "not set" to "set", the HSS sends a UE- 
REACHABILITY-NOTIFICATION-REQUEST (URRP-MME) to the MME. If the MME has an MM context 
for that user, the MME sets URRP-MME to indicate the need to report to the HSS information regarding changes 
in UE reachability, e.g. when the next NAS activity with that UE is detected. 

5.3.1 1 .3 UE Activity Notification procedure 

The UE Activity Notification procedure is illustrated in Figure 5.3.1 1.3-1. 
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Figure 5.3.1 1 .3-1 : UE Activity Procedure 

1) The MME receives an indication regarding UE reachability, e.g. an Attach Request message from the UE or 
MME receive an indication from S-GW that UE has handed over to non-3GPP coverage. 

2) If the MME contains an MM context of the UE and if URRP-MME for that UE is configured to report once that 
the UE is reachable, the MME shall send a UE-Activity-Notification (IMSI, UE-Reachable) message to the HSS 
and clears the corresponding URRP-MME for that UE. 

3) When the HSS receives the UE-Activity-Notification (IMSI, UE-Reachable) message or the Update Location 
message for an UE that has URRP-MME set, it triggers appropriate notifications to the entities that have 
subscribed to the HSS for this notification and clears the URRP-MME for that UE. 
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5.4 Session Management, QoS and interaction with PCC 
functionality 

5.4.1 Dedicated bearer activation 

The dedicated bearer activation procedure for a GTP based S5/S8 is depicted in figure 5.4.1-1. 
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Figure 5.4.1-1: Dedicated Bearer Activation Procedure 

NOTE 1: Steps 3-10 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For an 
PMlP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 11 and 12 
concern GTP based S5/S8. 

1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS policy) message to the PDN GW. 
This corresponds to the initial steps of the PCRF-Initiated IP-CAN Session Modification procedure or to the 
PCRF response in the PCEF initiated IP -CAN Session Modification procedure as defined in TS 23.203 [6], up to 
the point that the PDN GW requests IP-CAN Bearer Signalling. If dynamic PCC is not deployed, the PDN GW 
may apply local QoS policy. 

2. The PDN GW uses this QoS policy to assign the EPS Bearer QoS, i.e., it assigns the values to the bearer level 
QoS parameters QCI, ARP, GBR and MBR; see clause 4.7.3. The PDN GW sends a Create Bearer Request 
message (IMSI, PTI, EPS Bearer QoS, TFT, S5/S8 TEID, Charging Id, LBI, Protocol Configuration Options) to 
the Serving GW, the Linked EPS Bearer Identity (LBI) is the EPS Bearer Identity of the default bearer. The 
Procedure Transaction Id (PTI) parameter is only used when the procedure was initiated by a UE Requested 
Bearer Resource Modification Procedure - see clause 5.4.5. Protocol Configuration Options may be used to 
transfer application level parameters between the UE and the PDN GW (see TS 23.228 [52]), and are sent 
transparently through the MME and the Serving GW. 

NOTE: The PCO is sent in the dedicated bearer activation procedure either in response to a PCO received from 
the UE, or without the need to send a response to a UE provided PCO e.g. when the network wants the 
bearer to be dedicated for IMS signalling. 

3. The Serving GW sends the Create Bearer Request (IMSI, PTI, EPS Bearer QoS, TFT, Sl-TEID, PDN GW TEID 
(GTP -based S5/S8), LBI, Protocol Configuration Options) message to the MME. If the UE is in ECM-IDLE 
state the MME will trigger the Network Triggered Service Request from step 3 (which is specified in clause 
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5.3.4.3). In that case the following steps 4-7 may be combined into Network Triggered Service Request 
procedure or be performed standalone. 

4. The MME selects an EPS Bearer Identity, which has not yet been assigned to the UE. The MME then builds a 
Session Management Request including the PTI, TFT, EPS Bearer QoS parameters (excluding ARP), Protocol 
Configuration Options, the EPS Bearer Identity and the Linked EPS Bearer Identity (LB I). If the UE has 
UTRAN or GERAN capabilities and the network supports mobility to UTRAN or GERAN, the MME uses the 
EPS bearer QoS parameters to derive the corresponding PDP context parameters QoS Negotiated (R99 QoS 
profile). Radio Priority, Packet Flow Id and TI and includes them in the Session Management Request. If the UE 
indicated in the UE Network Capability it does not support BSS packet flow procedures, then the MME shall not 
include the Packet Flow Id. The MME then signals the Bearer Setup Request (EPS Bearer Identity, EPS Bearer 
QoS, Session Management Request, Sl-TEID) message to the eNodeB. 

5. The eNodeB maps the EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC Connection 
Reconfiguration (Radio Bearer QoS, Session Management Request, EPS RB Identity) message to the UE. The 
UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session 
Management Request, for use when accessing via GERAN or UTRAN. The UE NAS stores the EPS Bearer 
Identity and links the dedicated bearer to the default bearer indicated by the Linked EPS Bearer Identity (LBI). 
The UE uses the uplink packet filter (UL TFT) to determine the mapping of traffic flows to the radio bearer. The 
UE may provide the EPS Bearer QoS parameters to the application handling the traffic flow. The application 
usage of the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC Connection 
Reconfiguration on the basis of the EPS Bearer QoS parameters contained in the Session Management Request. 

NOTE 2: The details of the Radio Bearer QoS are specified in TS 36.300 [5]. 

6. The UE acknowledges the radio bearer activation to the eNodeB with a RRC Connection Reconfiguration 
Complete message. 

7. The eNodeB acknowledges the bearer activation to the MME with a Bearer Setup Response (EPS Bearer 
Identity, Sl-TEID) message. The eNodeB indicates whether the requested EPS Bearer QoS could be allocated or 
not. 

8. The UE NAS layer builds a Session Management Response including EPS Bearer Identity. The UE then sends a 
Direct Transfer (Session Management Response) message to the eNodeB. 

9. The eNodeB sends an Uplink NAS Transport (Session Management Response) message to the MME. 

10. Upon reception of the Bearer Setup Response message in step 7 and the Session Management Response message 
in step 9, the MME acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response 
(EPS Bearer Identity, Sl-TEID) message. 

1 1 . The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Bearer Response (EPS 
Bearer Identity, S5/S8-TEID) message. 

12. If the dedicated bearer activation procedure was triggered by a PCC Decision Provision message from the PCRF, 
the PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not, 
allowing the completion of the PCRF-Initiated IP -CAN Session Modification procedure or the PCEF initiated 
IP-CAN Session Modification procedure as defined in TS 23.203 [6], after the completion of IP-CAN bearer 
signalling. 

NOTE 3: The exact signalling of step 1 and 12 (e.g. for local break-out) is outside the scope of this specification. 
This signalling and its interaction with the dedicated bearer activation procedure are to be specified in 
TS 23.203 [6]. Steps 1 and 12 are included here only for completeness. 

5.4.2 Bearer modification witii bearer QoS update 

5.4.2.1 PDN GW initiated bearer modification witin bearer QoS update 

The PDN GW initiated bearer modification procedure (including EPS Bearer QoS update) for a GTP based S5/S8 is 
depicted in figure 5.4.2.1-1. This procedure is used in cases when one or several of the EPS Bearer QoS parameters 
QCI, GBR, MBR or ARP are modified (including the QCI or the ARP of the default EPS bearer e.g. due to the HSS 
Initiated Subscribed QoS Modification procedure, as described in clause 5.4.2.2) or to modify the APN-AMBR. 
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Modification fi-om a QCI of resource type non-GBR to a QCI of resource type GBR and vice versa is not supported by 
this procedure. 

NOTE 1 : The QCI of an existing dedicated bearer should only be modified if no additional bearer can be 
established with the desired QCI. 
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Figure 5.4.2.1-1 : Bearer Modification Procedure with Bearer QoS Update 

NOTE 2: Steps 3-10 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 11 and 12 
concern GTP based S5/S8. 

1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS policy) message to the PDN GW. 
This corresponds to the initial steps of the PCRF-Initiated IP-CAN Session Modification procedure or to the 
PCRF response in the PCEF initiated IP -CAN Session Modification procedure as defined in TS 23.203 [6], up to 
the point that the PDN GW requests IP-CAN Bearer Signalling. If dynamic PCC is not deployed, the PDN GW 
may apply local QoS policy. 

2. The PDN GW uses this QoS policy to determine that the authorized QoS of a service data flow has changed or 
that a service data flow shall be aggregated to or removed from an active bearer. The PDN GW generates the 
TFT and updates the EPS Bearer QoS to match the traffic flow aggregate. The PDN GW then sends the Update 
Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, TFT) message to the Serving GW. 
The Procedure Transaction Id (PTI) parameter is used when the procedure was initiated by a UE Requested 
Bearer Resource Modification Procedure - see clause 5.4.5. For APN-AMBR, the EPS bearer identity must refer 
to a non-GBR bearer. 

3. The Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, TFT, 
APN-AMBR) message to the MME. If the UE is in ECM-IDLE state the MME will trigger the Network 
Triggered Service Request from step 3 (which is specified in clause 5.3.4.3). In that case the following steps 4-7 
may be combined into Network Triggered Service Request procedure or be performed standalone. If only the 
QoS parameter ARP is modified and if the UE is in ECM IDLE state the MME shall skip the Network Triggered 
Service Request. In that case the following steps 4-9 are also skipped. 

NOTE 3: If ISR is activated and the Serving GW does not have a downlink S 1-U and the SGSN has notified the 

Serving GW that the UE has moved to PMM-IDLE or STANDBY state, the Serving GW sends Downlink 
Data Notification to trigger MME and SGSN to page the UE (as specified in clause 5.3.4.3) before 
sending the Update Bearer Request message. 

4. The MME builds a Session Management Request including the PTI, EPS Bearer QoS parameters (excluding 
ARP), TFT, APN-AMBR and EPS Bearer Identity. If the UE has UTRAN or GERAN capabilities and the 
network supports mobility to UTRAN or GERAN, the MME uses the EPS Bearer QoS parameters to derive the 
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corresponding PDP context parameters QoS Negotiated (R99 QoS profile), Radio Priority and Packet Flow Id 
and includes them in the Session Management Request. If the UE indicated in the UE Network Capability it does 
not support BSS packet flow procedures, then the MME shall not include the Packet Flow Id. If the APN-AMBR 
has changed the MME may update the UE-AMBR if appropriate. The MME then sends the Bearer Modify 
Request (EPS Bearer Identity, EPS Bearer QoS, Session Management Request, UE-AMBR) message to the 
eNodeB. 

5. The eNodeB maps the modified EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC Connection 
Reconfiguration (Radio Bearer QoS, Session Management Request, EPS RB Identity) message to the UE. The 
UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id, which it received in the Session Management 
Request, for use when accessing via GERAN or UTRAN. If the APN-AMBR has changed, the UE stores the 
modified APN-AMBR value and sets the MBR parameter of the corresponding non-GBR PDP contexts (of this 
PDN connection) to the new value. The UE uses the uplink packet filter (UL TFT) to determine the mapping of 
traffic flows to the radio bearer. The UE may provide EPS Bearer QoS parameters to the application handling the 
traffic flow(s). The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not 
reject the Radio Bearer Modify Request on the basis of the EPS Bearer QoS parameters contained in the Session 
Management Request. The UE shall set its TIN to "GUTI" if the modified EPS bearer was established before 
ISR activation. 

NOTE 4: The details of the Radio Bearer QoS are specified in TS 36.300 [5]. 

6. The UE acknowledges the radio bearer modification to the eNodeB with a RRC Connection Reconfiguration 
Complete message. 

7. The eNodeB acknowledges the bearer modification to the MME with a Bearer Modify Response (EPS Bearer 
Identity) message. With this message, the eNodeB indicates whether the requested EPS Bearer QoS could be 
allocated or not. 

8. The UE NAS layer builds a Session Management Response including EPS Bearer Identity. The UE then sends a 
Direct Transfer (Session Management Response) message to the eNodeB. 

9. The eNodeB sends an Uplink NAS Transport (Session Management Response) message to the MME. 

10. Upon reception of the Bearer Modify Response message in step 7 and the Session Management Response 
message in step 9, the MME acknowledges the bearer modification to the Serving GW by sending an Update 
Bearer Response (EPS Bearer Identity) message. 

1 1 . The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

12. If the Bearer modification procedure was triggered by a PCC Decision Provision message from the PCRF, the 
PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not by 
sending a Provision Ack message allowing the completion of the PCRF-Initiated IP-CAN Session Modification 
procedure or the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], after the 
completion of IP -CAN bearer signalling. 

NOTE 5: The exact signalling of step 1 and 12 (e.g. for local break-out) is outside the scope of this specification. 
This signalling and its interaction with the bearer activation procedure are to be specified in 
TS 23.203 [6]. Steps 1 and 12 are included here only for completeness. 

5.4.2.2 HSS Initiated Subscribed QoS Modification 

The HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8 is depicted in figure 5.4.2.2-1. 
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Figure 5.4.2.2-1 : HSS Initiated Subscribed QoS Modification 

NOTE 1: For a PMIP -based S5/S8, procedure steps (A) and steps (B) are defined in TS 23.402 [2]. Steps 3, 4, 5, 7 
and 8 concern GTP based S5/S8. 

1. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the MME. The Subscription 
Data includes EPS subscribed QoS (QCI, ARP) and the subscribed UE-AMBR and APN-AMBR. 

la. The MME updates the stored Subscription Data and acknowledges the Insert Subscriber Data message by 
returning an Insert Subscriber Data Ack (IMSI) message to the HSS (see clause 5.3.9.2). 

2a If only the subscribed UE-AMBR has been modified, the MME calculates a new UE-AMBR value as described 
in clause 4.7.3 and may then signal a modified UE-AMBR value to the eNodeB by using Sl-AP UE Context 
Modification Procedure. The HSS Initiated Subscribed QoS Modification Procedure ends after completion of the 
UE Context Modification Procedure. 

2b. If the QCI and/or ARP and/or subscribed APN-AMBR has been modified and there is related active PDN 
connection with the modified QoS Profile the MME sends the Modify Bearer Command (EPS Bearer Identity, 
EPS Bearer QoS, APN-AMBR) message to the Serving GW. The EPS Bearer Identity identifies the default 
bearer of the affected PDN connection. The EPS Bearer QoS contains the EPS subscribed QoS profile to be 
updated. 

3. The Serving GW sends the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN-AMBR) 
message to the PDN GW. 

4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the updated EPS Bearer QoS and APN- 
AMBR. The PCRF sends new updated PCC decision to the PDN GW. This corresponds to the PCEF-initiated 
IP-CAN Session Modification procedure as defined in TS 23.203 [6]. 

The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP) associated with the default 
bearer in the response to the PDN GW as defined in TS 23.203 [6]. 

5. The PDN GW modifies the default bearer of each PDN connection corresponding to the APN for which 
subscribed QoS has been modified. If the subscribed ARP parameter has been changed, the PDN GW shall also 
modify all dedicated EPS bearers having the previously subscribed ARP value unless superseded by PCRF 
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decision. The PDN GW then sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS, TFT, 
APN-AMBR) message to the Serving GW. 

NOTE 2: As no PTI is included the MME use protocol specific details, as described in TS 29.274 [43], to determine 
if the Update Bearer Request was triggered by this procedure or not. 

6. If the QCI and/or ARP parameter(s) have been modified, steps 3 to 10, as described in clause 5.4.2.1, Figure 
5.4.2.1-1, are invoked. If neither the QCI nor the ARP have been modified, but instead only the APN-AMBR 
was updated, steps 3 to 8, as described in clause 5.4.3, Figure 5.4.3-1, are invoked. 

7. The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. If the bearer modification fails the PDN GW deletes the concerned EPS Bearer. 

8. The PDN GW indicates to the PCRF whether the requested PCC decision was enforced or not by sending a 
Provision Ack message. 

5.4.3 PDN GW initiated bearer modification witinout bearer QoS update 

The bearer modification procedure without bearer QoS update is used to update the TFT for an active default or 
dedicated bearer, or to modify the APN-AMBR. 

NOTE 1 : If neither the contents of the TFT nor the APN-AMBR are modified, this procedure does not apply. 

The procedure for a GTP based S5/S8 is depicted in figure 5.4.3-1. In this procedure there is no need to update the 
underlying radio bearer(s). This procedure may be triggered if the APN-AMBR is changed by the PCRF/PDN GW. 
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Figure 5.4.3-1 : Bearer Modification Procedure without Bearer QoS Update 

NOTE 2: Steps 3-8 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For an 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 9 and 10 
concern GTP based S5/S8. Steps 3-8 may also be used within the HSS Initiated Subscribed QoS 
Modification. 

1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS policy) message to the PDN GW. 
This corresponds to the beginning of the PCRF-initiated IP-CAN Session Modification procedure or to the 
PCRF response in the PCEF initiated IP -CAN Session Modification procedure as defined in TS 23.203 [6], up to 
the point that the PDN GW requests IP-CAN Bearer Signalling. If dynamic PCC is not deployed, the PDN GW 
may apply local QoS policy. 
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2. The PDN GW uses this QoS policy to determine that a service data flow shall be aggregated to or removed from 
an active bearer. The PDN GW generates the TFT and determines that no update of the EPS Bearer QoS is 
needed. The PDN GW then sends the Update Bearer Request (PTI, EPS Bearer Identity, APN-AMBR, TFT) 
message to the Serving GW. The Procedure Transaction Id (PTI) parameter is used when the procedure was 
initiated by a UE Requested Bearer Resource Modification procedure - see clause 5.4.5. 

3. The Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, APN-AMBR, TFT) message to 
the MME. If the UE is in ECM-IDLE state the MME will trigger the Network Triggered Service Request from 
step 3 (which is specified in clause 5.3.4.3). In that case the following steps 4-7 may be combined into Network 
Triggered Service Request procedure or be performed standalone. 

4. The MME builds a Session Management Request message including the TFT, APN-AMBR and EPS Bearer 
Identity. The MME then sends a Downlink NAS Transport (Session Management Configuration) message to the 
eNodeB. If the APN AMBR has changed, the MME may also update the UE AMBR. And if the UE-AMBR is 
updated, the MME signal a modified UE-AMBR value to the eNodeB by using Sl-AP UE Context Modification 
Procedure. 

5. The eNodeB sends the Direct Transfer (Session Management Request) message to the UE. The UE uses the 
uplink packet filter (UL TFT) to determine the mapping of traffic flows to the radio bearer. The UE stores the 
modified APN-AMBR value and sets the MBR parameter of the corresponding non-GBR PDP contexts (of this 
PDN connection) to the new value. The UE shall set its TIN to "GUTI" if the modified EPS bearer was 
established before ISR activation. 

6. The UE NAS layer builds a Session Management Response including EPS Bearer Identity. The UE then sends a 
Direct Transfer (Session Management Response) message to the eNodeB. 

7. The eNodeB sends an Uplink NAS Transport (Session Management Response) message to the MME. 

8. The MME acknowledges the bearer modification to the Serving GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

9. The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

10. If the bearer modification procedure was triggered by a PCC Decision Provision message from the PCRF, the 
PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not by 
sending a Provision Ack message. This then allows the PCRF-Initiated IP -CAN Session Modification procedure 
or the PCEF initiated IP -CAN Session Modification procedure as defined in TS 23.203 [6] to continue and 
eventually conclude, proceeding after the completion of IP-CAN bearer signalling. 

NOTE 3: The exact signalling of step 1 and 10 (e.g. for local break-out) is outside the scope of this specification. 
This signalling and its interaction with the bearer activation procedure are to be specified in 
TS 23.203 [6]. Steps 1 and 10 are included here only for completeness. 

5.4.4 Bearer deactivation 

5.4.4.1 PDN GW initiated bearer deactivation 

The bearer deactivation procedure for a GTP based S5/S8 is depicted in figure 5.4.4.1-1. In this procedure, the UE is 
assumed to be in ECM-CONNECTED. This procedure can be used to deactivate a dedicated bearer or deactivate all 
bearers belonging to a PDN address. If the default bearer belonging to a PDN connection is deactivated, the PDN GW 
deactivates all bearers belonging to the PDN connection. 
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Figure 5.4.4.1-1: PDN GW Initiated Bearer Deactivation, UE in active mode 

NOTE 1: Steps 3-8 are common for architecture variants with GTP based S5/S8 and PMlP-based S5/S8. For an 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 9 and 10 
concern GTP -based S5/S8. 

1 . If dynamic PCC is not deployed, the PDN GW is triggered to initiate the Bearer Deactivation procedure due 
either a QoS policy or on request from the MME (as outlined in clause 5.4.4.2) or on intra-node signalling 
request from the HeNB to release the LIPA PDN Connection. Optionally, the PCRF sends QoS policy to the 
PDN GW. This corresponds to the initial steps of the PCRF-initiated IP -CAN Session Modification procedure or 
the response to the PCEF initiated IP -CAN Session Modification procedure as defined in TS 23.203 [6], up to 
the point that the PDN GW requests IP-CAN Bearer Signalling. If dynamic PCC is not deployed, the PDN GW 
may apply local QoS policy. The PDN GW initiated Bearer deactivation is also performed when handovers 
without optimization occurs from 3GPP to non-3GPP, in which case, the default bearer and all the dedicated 
bearers associated with the PDN address are released, but the PDN address is kept in the PDN GW. 

For an emergency PDN connection the PDN GW initiates the deactivation of all bearers of that emergency PDN 
connection when the PDN connection is inactive (i.e. not transferring any packets) for a configured period of 
time or when triggered by dynamic PCC. 

2. The PDN GW sends a Delete Bearer Request (PTI, EPS Bearer Identity, Causes) message to the Serving GW. 
The Procedure Transaction Id (PTI) parameter in this step and in the following steps is only used when the 
procedure was initiated by a UE Requested Bearer Resource Modification Procedure - see clause 5.4.5. This 
message can include an indication that all bearers belonging to that PDN connection shall be released. The PDN 
GW includes 'Cause' IE in the Delete Bearer Request message and sets the IE to 'RAT changed from 3GPP to 
Non-3GPP' if the Delete Bearer Request message is caused by handover without optimization occurs from 3GPP 
to non-3GPP. 

3a. The Serving GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause) message to the MME. This 
message can include an indication that all bearers belonging to that PDN connection shall be released. 
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3b. If ISR is activated, the Serving GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause) message 
to the SGSN. This message can include an indication that all bearers belonging to that PDN connection shall be 
released, and the SGSN releases all bearer resources of the PDN connection. 

NOTE 2: If all the bearers belonging to a UE are released due to handover without optimization occurs from 3GPP 
to non-3GPP, the SGSN changes the MM state of the UE to IDLE (GERAN network) or PMM- 
DETACHED (UTRAN network). 

4a. If the last PDN connection of the UE is being released and the bearer deletion is neither due to ISR deactivation 
nor due to handover to non-3GPP accesses, the MME explicitly detaches the UE by sending a Detach Request 
message to the UE. If the UE is in ECM-IDLE state the MME pages the UE. Steps 4b to 7b are skipped in this 
case, and the procedure continues from step 7c. 

4b. If the release of the bearer in E-UTRAN has already been signalled to the MME, steps 4-7 are omitted. 

Otherwise, if this is not the last PDN connection for the UE which is being released, the MME sends the Sl-AP 
Deactivate Bearer Request (EPS Bearer Identity) message to the eNodeB. The MME builds a NAS Deactivate 
EPS Bearer Context Request message including the EPS Bearer Identity, and includes it in the Sl-AP Deactivate 
Bearer Request message. When the bearer deactivation procedure was originally triggered by a UE request, the 
NAS Deactivate EPS Bearer Context Request message includes the PTI. 

5. The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to 
release and the NAS Deactivate EPS Bearer Context Request message to the UE. 

6a. The UE RRC releases the radio bearers indicated in the RRC message in step 5, and indicates the radio bearer 
status to the UE NAS. Then the UE NAS removes the UL TFTs and EPS Bearer Identity according to the radio 
bearer status indication from the UE RRC. The UE responds to the RRC Connection Reconfiguration Complete 
message to the eNodeB. 

6b. The eNodeB acknowledges the bearer deactivation to the MME with a Deactivate Bearer Response (EPS Bearer 
Identity) message. 

7a The UE NAS layer builds a Deactivate EPS Bearer Context Accept message including EPS Bearer Identity. The 
UE then sends a Direct Transfer (Deactivate EPS Bearer Context Accept) message to the eNodeB. 

7b. The eNodeB sends an Uplink NAS Transport (Deactivate EPS Bearer Context Accept) message to the MME. 

7c. If the UE receives the Detach Request message from the MME in the step 4a, the UE sends a Detach Accept 
message to the MME any time after step 4a. The eNodeB forwards this NAS message to the MME along with 
the TAIh-ECGI of the cell which the UE is using. 

NOTE 3: The UE may not be able to send this message, e.g. when the UE is out of coverage of E-UTRAN due to 
mobility to non-3GPP access. 

8a. The MME deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

8b The SGSN deletes PDP Context related to the deactivated EPS bearer and acknowledges the bearer deactivation 
to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

9. If ISR is activated, after receiving the two Delete Bearer Response messages from the MME and the SGSN, or if 
ISR is not activated, after receiving the Delete Bearer Response messages from the MME, the Serving GW 
deletes the bearer context related to the deactivated EPS bearer acknowledges the bearer deactivation to the PDN 
GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

10. The PDN GW deletes the bearer context related to the deactivated EPS bearer. If the dedicated bearer 
deactivation procedure was triggered by receiving a PCC decision message from the PCRF, the PDN GW 
indicates to the PCRF whether the requested PCC decision was successfully enforced by completing the PCRF- 
initiated IP-CAN Session Modification procedure or the PCEF initiated IP-CAN Session Modification procedure 
as defined in TS 23.203 [6], proceeding after the completion of IP -CAN bearer signalling. 

1 1 . If the UE is being explicitly detached , the MME releases the S 1 -MME signalling connection for the UE by 
sending an SI Release Command (Cause) message to the eNodeB. The details of this step are covered in the "SI 
Release Procedure", as described in clause 5.3.5 by step 4 to step 6. 
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NOTE 4: The exact signalling of step 1 and 10 (e.g. for local break-out) is outside the scope of this specification. 
This signalling and its interaction with the dedicated bearer activation procedure are to be specified in 
TS 23.203 [6]. Steps 1 and 10 are included here only for completeness. 

Steps 4 to 7 are not performed when the UE is in (a) ECM-IDLE and the last PDN connection of the UE is not being 
deleted or (b) UE is in ECM-IDLE and the last PDN connection is deleted due to ISR deactivation or due to handover to 
non-3GPP access. The EPS bearer state is synchronized between the UE and the network at the next ECM-IDLE to 
ECM-CONNECTED transition (e.g. Service Request or TAU procedure). 

If all the bearers belonging to a UE are released, the MME shall change the MM state of the UE to EMM- 
DEREGISTERED and the MME sends the SI Release Command to the eNodeB, which initiates the release of the RRC 
connection for the given UE if it is not released yet, and returns an S 1 Release Complete message to the MME. 

If all bearers of an emergency attached UE are deactivated the MME may initiate the explicit MME-Initiated Detach 
procedure. Regardless of the outcome of any explicit Detach procedure the MME changes the EMM state of the UE to 
EMM-DEREGISTERED and the MME sends the SI Release Command to the eNodeB if it is not yet released. 

If the default bearer belonging to a PDN connection is deactivated, the MME determines the Maximum APN 
Restriction for the remaining PDN connections and stores this new value for the Maximum APN Restriction. In 
addition if ISR is activated the SGSN determines the Maximum APN Restriction for the remaining bearer contexts and 
stores this new value for the Maximum APN Restriction. 



5.4.4.2 



MME Initiated Dedicated Bearer Deactivation 



MME initiated Dedicated Bearer Deactivation is depicted in Figure 5.4.4.2-1 below. This procedure deactivates 
dedicated bearers. Default bearers are not affected. To initiate the release of the full PDN connection including the 
default bearer, the MME uses the UE or MME requested PDN disconnection procedure defined in clause 5.10.3. 

In case of eNodeB Failure, MME may, based on operator policy, either preserve all bearers or initiate the Dedicated 
Bearer Deactivation procedure, as shown in Figure 5.4.4.2-1 below. In deactivating the GBR bearers, MME may take 
the EPS bearer QoS into account. 



UE 



eNodeB 



MME 



Serving GW 



PDNGW 



PCRF 



0. Radio Bearer Release 



1 . Indication of Bearer Release 




2. Delete Bearer Command 



3. Delete Bearer Command 



(A) 



4. PCEF Initiated IP-CAN 
Session Modification 



5. Delete Bearer Request 



6. Delete Bearer Request 



7. Procedure as in TS 23.401, 

Figure 5.4.4.1-1 , between step 4 and step 7 



8. Delete Bearer Response 



9. Delete Bearer 
Response 



(B) 



Figure 5.4.4.2-1 : MME initiated Dedicated Bearer Deactivation 

NOTE: For a PMIP -based S5/S8, procedure steps (A) and steps (B) are defined in TS 23.402 [2]. Steps 3, 4, 5 
and 9 concern GTP based S5/S8 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 10 1 44 ETSI TS 1 23 401 V1 0.3.0 (201 1 -03) 

0. Radio bearers for the UE in the ECM-CONNECTED state may be released due to local reasons (e.g. abnormal 
resource limitation or radio conditions do not allow the eNodeB to maintain all the allocated GBR bearers: it is 
not expected that non-GBR bearers are released by the eNodeB unless caused by error situations). The UE 
deletes the bearer contexts related to the released radio bearers. 

1 . When the eNodeB releases radio bearers in step 0, it sends an indication of bearer release to the MME. This 
indication may be e.g. the Bearer Release Request (EPS Bearer Identity) message to the MME, or alternatively 
Initial Context Setup Complete, Handover Request Ack and UE Context Response, Path Switch Request may 
also indicate the release of a bearer. 

2. The MME sends the Delete Bearer Command (EPS Bearer Identity) message per PDN connection to the Serving 
GW to deactivate the selected dedicated bearer. 

3. The Serving GW sends the Delete Bearer Command (EPS Bearer Identity) message per PDN connection to the 
PDN GW. 

4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the loss of resources by means of a 
PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6]. The PCRF sends a updated 
PCC decision to the PDN GW. 

5. The PDN GW sends a Delete Bearer Request (EPS Bearer Identity) message to the Serving GW. 

6. The Serving GW sends the Delete Bearer Request (EPS Bearer Identity) message to the MME. 

7. Steps between steps 4 and 7, as described in clause 5.4.4.1, are invoked. This is omitted if the bearer deactivation 
was triggered by the eNodeB in step and step 1 . 

8. The MME deletes the bearer contexts related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

9. The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the PDN GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

5.4.5 UE requested bearer resource modification 

The UE requested bearer resource modification procedure for an E-UTRAN is depicted in figure 5.4.5-1. The procedure 
allows the UE to request for a modification of bearer resources (e.g. allocation or release of resources) for one traffic 
flow aggregate with a specific QoS demand. Alternatively, the procedure allows the UE to request for the modification 
of the packet filters used for an active traffic flow aggregate, without changing QoS. If accepted by the network, the 
request invokes either the Dedicated Bearer Activation Procedure, the Bearer Modification Procedure or a dedicated 
bearer is deactivated using the PDN GW Initiated Bearer Deactivation Procedure. The procedure is used by the UE 
when the UE already has a PDN connection with the PDN GW. A UE can send a subsequent Request Bearer Resource 
Modification Message before the previous procedure is completed. 

In this procedure the UE signals a Traffic Aggregate Description (TAD) which is a partial TFT, together with a 
Procedure Transaction Identifier (PTI), and an EPS Bearer Identity (when the TAD operation is modify, delete or add to 
an existing packet filter). When the TAD operation is modify or delete, the packet filter identifiers of the TAD are the 
same as the TFT packet filter identifiers of the referenced EPS Bearer (as the concatenation of the TFT packet filter 
identifier and the EPS Bearer identifier represents a unique packet filter identifier within the PDN connection), for 
which resources are being modified. The TAD is released by the UE after it has received a TFT related to the current 
PTI from the network. 
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Figure 5.4.5-1: UE requested bearer resource modification 

NOTE: Steps 1, 2, and 5 are common for architecture variants with GTP-based S5/S8 and PMIP -based S5/S8. 
The procedure steps marked (A) differ in the case that PMIP-based S5/S8 is employed and is defined in 
TS 23.402 [2]. 

1. The UE sends a Request Bearer Resource Modification (LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol 
Configuration Options) message to the MME. If the UE was in ECM-IDLE mode, this NAS message is preceded 
by the Service Request procedure. 

The TAD indicates one requested operation (add, modify, or delete packet filters). If traffic flows are added, the 
TAD includes the packet filter(s) (consisting of the packet filter information including packet filter precedence, 
but without a packet filter identifier) to be added. The UE also sends the QCI requested and GBR, if applicable, 
for the added traffic flows. If the UE wants to link the new packet filter to an existing packet filter to enable the 
usage of existing bearer resources for the new packet filter, the UE shall provide an existing packet filter 
identifier together with the new packet filter. If the UE wants to change the GBR in addition, the UE includes the 
GBR requirement of the EPS Bearer. The TAD is released when the procedure is completed. 

When requesting for a modification of GBR (i.e. decrease or increase), the TAD shall include packet filter 
identifier(s) for which the GBR change request applies to. The UE includes the GBR requirement of the EPS 
Bearer. The TAD is released when the procedure is completed. 

When requesting for a modification of a packet filter (e.g. change of port number), the TAD shall include packet 
filter identifier for which the change request applies to together with the changed packet filter information. 

If the UE requests for deletion of traffic flows, the TAD includes the packet filter identifier(s) to be deleted. If 
the packet filters to be deleted were mapped to a GBR Bearer, the UE includes the new GBR requirement of the 
EPS Bearer. 

The UE sends the Linked Bearer Id (LBI) only when the requested operation is add, to indicate to which PDN 
connection the additional bearer resource is linked to. The EPS Bearer Identity is only sent when the requested 
operation is modify or delete. The Procedure Transaction Id is dynamically allocated by the UE for this 
procedure. The UE should ensure as far as possible that previously used PTI values are not immediately reused. 
The PTI is released when the procedure is completed. Protocol Configuration Options may be used to transfer 
application level parameters between the UE and the PDN GW (see TS 23.228 [52]), and are sent transparently 
through the MME and the Serving GW. 

2. The MME sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol 
Configuration Options) message to the selected Serving GW. The MME validates the request using the Linked 
Bearer Id. The same Serving GW address is used by the MME as for the EPS Bearer identified by the Linked 
Bearer Id received in the Request Bearer Resource Modification message. 

3. The Serving GW sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, 
Protocol Configuration Options) message to the PDN GW. The Serving GW sends the message to the same PDN 
GW as for the EPS Bearer identified by the Linked Bearer Id. 
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4. The PDN GW may either apply a locally configured QoS policy, or it may interact with the PCRF to trigger the 
appropriate PCC decision, which may take into account subscription information. This corresponds to the 
beginning of a PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], up to the 
point that the PDN GW requests IP -CAN Bearer Signalling. When interacting with PCRF, the PDN GW 
provides to the PCRF the content of the TAD and, if applicable, the GBR change (increase or decrease) 
associated with the packet filter information contained in the TAD. The GBR change is either calculated from 
the current Bearer QoS and the requested Bearer QoS from the UE, or set to the requested GBR if the TAD 
indicates an add operation and no EPS Bearer Identity was received. If the TAD indicates an add operation, the 
requested QCI is also provided to the PCRF unless an existing packet filter identifier is provided together with 
the new packet filter. 

If the TAD operation is modify or delete, then the PDN GW provides the SDF filter identifier(s), previously 
assigned on Gx, that correspond to the received packet filter identifiers of the EPS bearer indicated by the 
received EPS bearer identity. 

5. If the request is accepted, either the Dedicated Bearer Activation Procedure (according to clause 5.4.1), the PDN 
GW Initiated Bearer Deactivation Procedure (according to clause 5.4.4.1) or one of the Dedicated Bearer 
Modification Procedures (according to clause 5.4.2.1 or 5.4.3) is invoked. The PTI allocated by the UE is used as 
a parameter in the invoked Dedicated Bearer Activation Procedure, the PDN GW Initiated Bearer Deactivation 
Procedure or the Dedicated Bearer Modification Procedure to correlate it to the UE Requested Bearer Resource 
Modification Procedure. This provides the UE with the necessary linkage to what EPS Bearer to be used for the 
new traffic flow aggregate. The PDN GW shall not modify the QoS parameters requested by the UE. 

The PDN GW inserts, modifies or removes packet filter(s) corresponding to the TAD into the TFT for the EPS 
bearer. When a new packet filter is inserted into a TFT, the PDN GW assigns a new packet filter identifier which 
is unique within the TFT. The PDN GW maintains the relation between the SDF filter identifier in the PCC rule 
received from the PCRF and the packet filter identifier of the TFT of this EPS bearer. If all of the packet filter(s) 
for a dedicated EPS bearer have been removed from the TFT, the PDN GW performs the PDN GW Initiated 
Bearer Deactivation Procedure. 

If the requested QoS is not granted (i.e. the requested QoS cannot be accepted or resources could not be 
allocated) the PDN GW sends a Bearer Resource Failure Indication (with a cause indicating the reason why the 
request failed or was rejected) message, which shall be delivered to the UE. 

6. If the PDN GW interacted with the PCRF in step 4, the PDN GW indicates to the PCRF whether the PCC 
decision could be enforced or not. This corresponds to the completion of the PCEF-initiated IP -CAN session 
modification procedure as defined in TS 23.203 [6], proceeding after the completion of IP -CAN bearer 
signalhng. 

5.4.6 Void 

5.5 Handover 

5.5.1 Intra-E-UTRAN handover 
5.5.1.1 X2-based handover 

5.5.1.1.1 General 

These procedures are used to hand over a UE from a source eNodeB to a target eNodeB using the X2 reference point. In 
these procedures the MME is unchanged. Two procedures are defined depending on whether the Serving GW is 
unchanged or is relocated. In addition to the X2 reference point between the source and target eNodeB, the procedures 
rely on the presence of S 1-MME reference point between the MME and the source eNodeB as well as between the 
MME and the target eNodeB. 
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The handover preparation and execution phases are performed as specified in TS 36.300 [5]. If emergency bearer 
services are ongoing for the UE handover to the target eNodeB is performed independent of the Handover Restriction 
List. The MME checks, as part of the Tracking Area Update in the execution phase, if the handover is to a restricted 
area and if so MME releases the non-emergency bearers as specified in clause 5. 10.3. 

If the serving PLMN changes during X2-based handover, the source eNodeB shall indicate to the target eNodeB (in the 
Handover Restriction List) the PLMN selected to be the new Serving PLMN. 

When the UE receives the handover command it will remove any EPS bearers for which it did not receive the 
corresponding EPS radio bearers in the target cell. As part of handover execution, downlink and optionally also uplink 
packets are forwarded from the source eNodeB to the target eNodeB. When the UE has arrived to the target eNodeB, 
downlink data forwarded from the source eNodeB can be sent to it. Uplink data from the UE can be delivered via the 
(source) Serving GW to the PDN GW or optionally forwarded from the source eNodeB to the target eNodeB. Only the 
handover completion phase is affected by a potential change of the Serving GW, the handover preparation and 
execution phases are identical. 

If the MME receives a rejection to a NAS procedure (e.g. dedicated bearer establishment/modification/release; location 
reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an X2 handover is in progress 
(see TS 36.300 [5]), the MME shall reattempt the same NAS procedure either when the handover is complete or the 
handover is deemed to have failed, except in case of Serving GW relocation. The failure is known by expiry of the timer 
guarding the NAS procedure. 

If during the handover procedure the MME detects that the Serving GW needs be relocated, the MME shall reject any 
PDN GW initiated EPS bearer(s) request received since handover procedure started and shall include an indication that 
the request has been temporarily rejected due to handover procedure in progress. The rejection is forwarded by the 
Serving GW to the PDN GW, with the same indication. 

Upon reception of a rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the request has 
been temporarily rejected due to handover procedure in progress, the PDN GW start a locally configured guard timer. 
The PDN GW shall re-attempt, up to a pre-configured number of times, when either it detects that the handover is 
completed or has failed using message reception or at expiry of the guard timer. 

If the MME receives a rejection to a UE Context Modification Request message with a CS Fallback indicator from the 
eNodeB with an indication that an X2 handover is in progress, the MME shall resend a UE Context Modification 
Request message with CS Fallback indicator to the target eNodeB when the handover is complete or to the source eNB 
when the handover is deemed to have failed. 

5.5.1 .1 .2 X2-based handover without Serving GW relocation 

This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is 
unchanged and decides that the Serving GW is also unchanged. The presence of IP connectivity between the Serving 
GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed. 
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Figure 5.5.1.1.2-1 : X2-based handover without Serving GW relocation 

NOTE 1: For a PMIP -based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. 

1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, 
including the TAI+ECGI of the target cell and the list of EPS bearers to be switched. If the target cell is a CSG 
cell , the target eNodeB includes the CSG ID of the target cell in Path Switch Request message. If the target cell 
is in hybrid mode, it includes the CSG ID of the target cell and CSG Access Mode set to "hybrid" in the Path 
Switch Request message. The MME determines the CSG membership based on the CSG ID and CSG Access 
Mode received from the target eNodeB. The MME updates the User CSG information based on the CSG ID and 
CSG Access Mode received from the target eNodeB and CSG membership if one of the parameters has changed. 

NOTE 2: X2 handover between HeNBs is possible when the handover is between closed/hybrid access HeNBs 
having the same CSG ID or when the target HeNB is an open access HeNB. 

The MME determines that the Serving GW can continue to serve the UE 

2. The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane for the 
accepted EPS bearers, ISR Activated) message per PDN connection to the Serving GW for each PDN connection 
where the default bearer has been accepted by the target eNodeB. If the PDN GW requested UE's location info, 
the MME also includes the User Location Information IE in this message. If the UE Time Zone has changed, the 
MME includes the UE Time Zone IE in this message. If the Serving Network has changed, the MME includes 
the new Serving Network IE in this message. If ISR was activated before this procedure, MME should maintain 
ISR. The UE is informed about the ISR status in the Tracking Area Update procedure. If the Serving GW 
supports Modify Access Bearers Request procedure and if there is no need for the SGW to send the signalling to 
the PGW, the MME may send Modify Access Bearers Request (eNodeB address(es) and TEIDs for downlink 
user plane for the accepted EPS bearers, ISR Activated) per UE to the Serving GW to optimize the signalling. 

If the PDN GW requested UE's User CSG information (determined from the UE context), the MME includes the 
User CSG Information IE in this message if the User CSG Information has changed. 
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The MME uses the list of EPS bearers to be switched, received in step 1 , to determine whether any dedicated 
EPS bearers in the UE context have not been accepted by the target eNodeB. The MME releases the non- 
accepted dedicated bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the 
Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not 
send a Downlink Data Notification to the MME. 

If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are multiple 
PDN connections active, the MME shall consider all bearers of that PDN connection as failed and release that 
PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3. 

If none of the default EPS bearers have been accepted by the target eNodeB, the MME shall act as specified in 
step 6. 

3. If the Serving GW has received the User Location Information IE and/or the UE Time Zone IE and/or the 
Serving Network IE and/or User CSG Information IE from the MME in step 2 the Serving GW informs the PDN 
GW(s) about this information that e.g. can be used for charging, by sending the message Modify Bearer Request 
(Serving GW Address and TEID, User Location Information IE and/or UE Time Zone IE and/or Serving 
Network IE and/or User CSG Information IE) per PDN connection to the PDN GW(s) concerned. The Serving 
GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) message to the 
MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving GW 
address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If the Serving 
GW cannot serve the MME Request in the Modify Access Bearers Request message without S5/S8 signalling or 
without corresponding Gxc signalling when PMIP is used over the S5/S8 interface, it shall respond to the MME 
with indicating that the modifications are not limited to Sl-U bearers, and the MME shall repeat its request using 
Modify Bearer Request message per PDN connection. 

4. The Serving GW starts sending downlink packets to the target eNodeB using the newly received address and 
TEIDs. A Modify Bearer Response message is sent back to the MME. 

5. In order to assist the reordering function in the target eNodeB, the Serving GW shall send one or more "end 
marker" packets on the old path immediately after switching the path as defined in TS 36.300 [5], 

clause 10.L2.2. 

6. The MME confirms the Path Switch Request message with the Path Switch Request Ack message. If the 
UE-AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are rejected in the target 
eNodeB, the MME shall provide the updated value of UE-AMBR to the target eNodeB in the Path Switch 
Request Ack message. 

If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path 
Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and for 
dedicated bearers initiate the bearer release procedure as specified in clause 5.4.4.2 to release the core network 
resources of the failed dedicated EPS bearers. The target eNodeB shall delete the corresponding bearer contexts 
when it is informed that bearers have not been established in the core network. 

If none of the default EPS bearers have been switched successfully in the core network or if they have not been 
accepted by the target eNodeB, the MME shall send a Path Switch Request Failure message (see more detail in 
TS 36.413 [36]) to the target eNodeB. The MME performs expHcit detach of the UE as described in the MME 
initiated detach procedure of clause 5.3.8.3. 

7. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers 
the release of resources. This step is specified in TS 36.300 [5]. 

8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for 
tracking area update" applies. If ISR is activated for the UE when the MME receives the Tracking Area Update 
Request, the MME should maintain ISR by indicating ISR Activated in the Tracking Area Update Accept 

message. 

NOTE 3: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in 
ECM-CONNECTED state and the MME is not changed. 

5.5.1 .1 .3 X2-based handover with Serving GW relocation 

This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is 
unchanged and the MME decides that the Serving GW is to be relocated. The presence of IP connectivity between the 
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source Serving GW and the source eNodeB, between the source Serving GW and the target eNodeB, and between the 
target Serving GW and target eNodeB is assumed. (If there is no IP connectivity between target eNodeB and source 
Serving GW, it is assumed that the SI -based handover procedure in clause 5.5.1.2 shall be used instead.) 
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Figure 5.5.1.1.3-1 : X2-based handover with Serving GW relocation 

NOTE 1: For a PMIP -based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. 

1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, 
including the ECGI of the target cell and the list of EPS bearers to be switched. If the target cell is a CSG cell , 
the target eNodeB includes the CSG ID of the target cell in Path Switch Request message. If the target cell is in 
hybrid mode, it includes the CSG ID of the target cell and CSG Access Mode set to "hybrid" in the Path Switch 
Request message. The MME determines the CSG membership based on the CSG ID and CSG Access Mode 
received from the target eNodeB. The MME updates the User CSG information based on the CSG ID and CSG 
Access Mode received from the target eNodeB and CSG membership if one of the parameters has changed. 

NOTE 2: X2 handover between HeNBs is possible when the handover is between closed/hybrid access HeNBs 
having the same CSG ID or when the target HeNB is an open access HeNB. 

The MME determines that the Serving GW is relocated and selects a new Serving GW according to clause 
4.3.8.2 on "Serving GW Selection Function". 

NOTE 3: The MME knows the S-GW Service Area with a TA granularity. 

2. The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs (for GTP- 
based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB address(es) 
and TEIDs for downlink user plane for the accepted EPS bearers, the Protocol Type over S5/S8, Serving 
Network, UE Time Zone) message per PDN connection to the target Serving GW for each PDN connection 
where the default bearer has been accepted by the target eNodeB. The target Serving GW allocates the S-GW 
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addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The Protocol Type 
over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. If the PDN GW 
requested UE's location info, the MME also includes the User Location Information IE in this message. If the 
PDN GW requested UE's User CSG information (determined from the UE context), the MME includes the User 
CSG Information IE in this message if the User CSG Information has changed. 

The MME uses the list of EPS bearers to be switched, received in step 1 , to determine whether any dedicated 
EPS bearers in the UE context have not been accepted by the target eNodeB. The MME releases the non- 
accepted dedicated bearers by triggering the bearer release procedure as specified in clause 5.4.4.2 via target 
Serving GW. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 
packet and does not send a Downlink Data Notification to the MME. 

If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are multiple 
PDN connections active, the MME shall consider all bearers of that PDN connection as failed and release that 
PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3 via 
source Serving GW. 

If none of the default EPS bearers have been accepted by the target eNodeB, the MME shall act as specified in 
step 5. 

3. The target Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. 
The Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify Bearer Request 
(Serving GW addresses for user plane and TEID(s), Serving Network) message per PDN connection to the PDN 
GW(s). The S-GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG 
Information IE if it is present in step 2. The PDN GW updates its context field and returns a Modify Bearer 
Response (Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW 
has it stored in its UE context. The PDN GW starts sending downlink packets to the target GW using the newly 
received address and TEIDs. These downlink packets will use the new downlink path via the target Serving GW 
to the target eNodeB. The Serving GW shall allocate TEIDs for the failed bearers and inform to the MME. 

4. The target Serving GW sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user 
plane) message back to the target MME. The MME starts a timer, to be used in step 7. 

5. The MME confirms the Path Switch Request message with the Path Switch Request Ack (Serving GW addresses 
and uplink TEID(s) for user plane) message. If the UE-AMBR is changed, e.g. all the EPS bearers which are 
associated to the same APN are rejected in the target eNodeB, the MME shall provide the updated value of 
UE-AMBR to the target eNodeB in the Path Switch Request Ack message. The target eNodeB starts using the 
new Serving GW address(es) and TEID(s) for forwarding subsequent uplink packets. 

If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path 
Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and for 
dedicated bearers initiate the bearer release procedure as specified in clause 5.4.4.2 to release the core network 
resources of the failed dedicated EPS bearers. The target eNodeB shall delete the corresponding bearer contexts 
when it is informed that bearers have not been established in the core network. 

If none of the default EPS bearers have been switched successfully in the core network or if they have not been 
accepted by the target eNodeB, the MME shall send a Path Switch Request Failure message (see more detail in 
TS 36.413 [36]) to the target eNodeB. The MME performs exphcit detach of the UE as described in the MME 
initiated detach procedure of clause 5.3.8.3. 

6. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers 
the release of resources. This step is specified in TS 36.300 [5]. 

7. When the timer has expired after step 4, the source MME releases the bearer(s) in the source Serving GW by 
sending a Delete Session Request message (Cause, Operation Indication). The operation Indication flag is not 
set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure 
towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response messages. If ISR 
has been activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW shall 
delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN 
node. 

8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for 
tracking area update" applies. 
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NOTE 4: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in 
ECM-CONNECTED state. The UE is informed about the ISR status in the Tracking Area Update 
procedure. 

5.5.1.2 S1 -based handover 

5.5.1.2.1 General 

The SI -based handover procedure is used when the X2 -based handover cannot be used. The source eNodeB initiates a 
handover by sending Handover Required message over the S 1-MME reference point. This procedure may relocate the 
MME and/or the Serving GW. The source MME selects the target MME. The MME should not be relocated during 
inter-eNodeB handover unless the UE leaves the MME Pool Area where the UE is served. The MME (target MME for 
MME relocation) determines if the Serving GW needs to be relocated. If the Serving GW needs to be relocated the 
MME selects the target Serving GW, as specified in clause 4.3.8.2 on Serving GW selection function. 

The source eNodeB decides which of the EPS bearers are subject for forwarding of downlink and optionally also uplink 
data packets from the source eNodeB to the target eNodeB. The EPC does not change the decisions taken by the RAN 
node. Packet forwarding can take place either directly from the source eNodeB to the target eNodeB, or indirectly from 
the source eNodeB to the target eNodeB via the source and target Serving GWs (or if the Serving GW is not relocated, 
only the single Serving GW). 

The availability of a direct forwarding path is determined in the source eNodeB and indicated to the source MME. If X2 
connectivity is available between the source and target eNodeBs, a direct forwarding path is available. 

If a direct forwarding path is not available, indirect forwarding may be used. The source MME uses the indication from 
the source eNodeB to determine whether to apply indirect forwarding. The source MME indicates to the target MME 
whether indirect forwarding should apply. Based on this indication, the target MME determines whether it applies 
indirect forwarding. 

If the MME receives a rejection to an SI interface procedure (e.g. dedicated bearer establishment/modification/release; 
location reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an SI handover is in 
progress (see TS 36.300 [5]), the MME shall reattempt the same SI interface procedure when either the handover is 
complete or is deemed to have failed if the MME is still the serving MME, except in case of Serving GW relocation. 

In order to minimise the number of procedures rejected by the eNodeB, the MME should pause non-handover related 
SI interface procedures (e.g. downlink NAS message transfer, E-RAB Setup/Modify/Release, etc.) while a handover is 
ongoing (i.e. from the time that a Handover Required has been received until either the Handover procedure has 
succeeded (Handover Notify) or failed (Handover Failure)) and continue them once the Handover procedure has 
completed if the MME is still the serving MME, except in case of Serving GW relocation. 

If during the handover procedure the MME detects that the Serving GW or/and the MME needs be relocated, the MME 
shall reject any PDN GW initiated EPS bearer(s) request received since handover procedure started and shall include an 
indication that the request has been temporarily rejected due to handover procedure in progress. The rejection is 
forwarded by the Serving GW to the PDN GW, with the same indication. 

Upon reception of a rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the request has 
been temporarily rejected due to handover procedure in progress, the PDN GW start a locally configured guard timer. 
The PDN GW shall re-attempt, up to a pre-configured number of times, when either it detects that the handover is 
completed or has failed using message reception or at expiry of the guard timer. 

If emergency bearer services are ongoing for the UE, handover to the target eNodeB is performed independent of the 
Handover Restriction List. The MME checks, as part of the Tracking Area Update in the execution phase, if the 
handover is to a restricted area and if so MME releases the non-emergency bearers as specified in clause 5.10.3. 

If the MME receives a rejection to a UE Context modification Request message with a CS Fallback indication from the 
eNodeB with an indication that an S 1 handover is in progress, the MME shall resend a UE Context Modification 
Request message with CS Fallback indicator to the target eNodeB when either the handover is complete or to the source 
eNodeB when the handover is deemed to have failed if the MME is still the serving MME. 
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5.5.1.2.2 S1 -based handover, normal 

This procedure describes the Sl-based handover in the normal case, clause 5.5.1.2.3 describes it when the procedure is 
rejected by the target eNodeB or the target MME and clause 5.5.1.2.4 describes when the procedure is canceled by the 
source eNodeB. 
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NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 16 and 16a 
concern GTP based S5/S8. 

NOTE 2: If the Serving GW is not relocated, the box "Source Serving GW" in figure 5.5.1.2.2-1 is acting as the 
target Serving GW. 

1. The source eNodeB decides to initiate an Sl-based handover to the target eNodeB. This can be triggered e.g. by 
no X2 connectivity to the target eNodeB, or by an error indication fi^om the target eNodeB after an unsuccessful 
X2-based handover, or by dynamic information learnt by the source eNodeB. 

2. The source eNodeB sends Handover Required (Direct Forwarding Path Availability, Source to Target 
transparent container, target eNodeB Identity, CSG ID, CSG access mode, target TAl, SlAP Cause) to the 
source MME. The source eNodeB indicates which bearers are subject to data forwarding. Direct Forwarding 
Path Availability indicates whether direct forwarding is available from the source eNodeB to the target eNodeB. 
This indication from source eNodeB can be based on e.g. the presence of X2. The target TAl is sent to MME to 
facilitate the selection of a suitable target MME. When the target cell is a CSG cell or a hybrid cell, the source 
eNodeB shall include the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall 
be indicated. 

3. The source MME selects the target MME as described in clause 4.3.8.3 on "MME Selection Function" and if it 
has determined to relocate the MME, it sends a Forward Relocation Request (MME UE context. Source to 
Target transparent container, RAN Cause, target eNodeB Identity, CSG ID, CSG Membership Indication, target 
TAl, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE 
Time Zone, Direct Forwarding Flag, Serving Network) message to the target MME. The target TAl is sent to the 
target MME to help it to determine whether S-GW relocation is needed (and, if needed, aid SGW selection). The 
old Serving Network is sent to target MME to support the target MME to resolve if Serving Network is changed. 
In network sharing scenarios Serving Network denotes the serving core network. 

The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided 
by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and 
the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause. 

The MME UE context includes IMSI, ME Identity, UE security context, UE Network Capability, AMBR, 
Selected CN operator ID, APN restriction. Serving GW address and TEID for control signalling, and EPS Bearer 
context(s). 

An EPS Bearer context includes the PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, APN, Serving GW addresses and TEIDs for uplink 
traffic, and TI. 

RAN Cause indicates the SlAP Cause as received from source eNodeB. 

The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG or 
hybrid cell. When the target cell is a hybrid cell, the CSG Membership Indication indicating whether the UE is a 
CSG member shall be included in the Forward Relocation Request message. 

The Direct Forwarding Flag indicates if direct forwarding is applied, or if indirect forwarding is going to be set 
up by the source side. 

The target MME shall determine the Maximum APN restriction based on the APN Restriction of each bearer 
context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction 
value. 

If the UE receives only emergency services and the UE is UlCCless, IMSI can not be included in the MME UE 
context in Forward Relocation Request message. For emergency attached UEs, if the IMSI cannot be 
authenticated, then the IMSI shall be marked as unauthenticated. Also, in this case, security parameters are 
included only if available. 

4. If the MME has been relocated, the target MME verifies whether the source Serving GW can continue to serve 
the UE. If not, it selects a new Serving GW as described in clause 4.3.8.2 on "Serving GW Selection Function". 
If the MME has not been relocated, the source MME decides on this Serving GW re-selection. 

If the source Serving GW continues to serve the UE, no message is sent in this step. In this case, the target 
Serving GW is identical to the source Serving GW. 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 10 1 56 ETSI TS 1 23 401 V1 0.3.0 (201 1 -03) 

If a new Serving GW is selected, the target MME sends a Create Session Request (bearer context(s) with PDN 
GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for 
uplink traffic, Serving Network, UE Time Zone) message per PDN connection to the target Serving GW. The 
target Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one 
TEID per bearer). The target Serving GW sends a Create Session Response (Serving GW addresses and uplink 
TEID(s) for user plane) message back to the target MME. 

5. The Target MME sends Handover Request (EPS Bearers to Setup, AMBR, SlAP Cause, Source to Target 
transparent container, CSG ID, CSG Membership Indication, Handover Restriction List) message to the target 
eNodeB. This message creates the UE context in the target eNodeB, including information about the bearers, and 
the security context. For each EPS Bearer, the Bearers to Setup includes Serving GW address and uplink TEID 
for user plane, and EPS Bearer QoS. If the direct forwarding flag indicates unavailability of direct forwarding 
and the target MME knows that there is no indirect data forwarding connectivity between source and target, the 
Bearers to Setup shall include "Data forwarding not possible" indication for each EPS bearer. Handover 
Restriction List is sent if available in the Target MME; it is described in clause 4.3.5.7 "Mobility Restrictions". 

SlAP Cause indicates the RAN Cause as received from source MME. 

The Target MME shall include the CSG ID and CSG Membership Indication when provided by the source MME 
in the Forward Relocation Request message. 

The target eNodeB sends a Handover Request Acknowledge (EPS Bearer Setup list, EPS Bearers failed to setup 
list Target to Source transparent container) message to the target MME. The EPS Bearer Setup list includes a list 
of addresses and TEIDs allocated at the target eNodeB for downlink traffic on Sl-U reference point (one TEID 
per bearer) and addresses and TEIDs for receiving forwarded data if necessary. If the UE-AMBR is changed, e.g. 
all the EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME shall 
recalculate the new UE-AMBR and signal the modified UE-AMBR value to the target eNodeB. 

If none of the default EPS bearers have been accepted by the target eNodeB, the target MME shall reject the 
handover as specified in clause 5.5.1.2.3. 

If the target cell is a CSG cell, the target eNodeB shall verify the CSG ID provided by the target MME, and 
reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target 
eNodeB is in hybrid mode, it may use the CSG Membership Indication to perform differentiated treatment for 
CSG and non-CSG members. 

6. If indirect forwarding applies and the Serving GW is relocated, the target MME sets up forwarding parameters 
by sending Create Indirect Data Forwarding Tunnel Request (target eNodeB addresses and TEIDs for 
forwarding) to the Serving GW. The Serving GW sends a Create Indirect Data Forwarding Tunnel Response 
(target Serving GW addresses and TEIDs for forwarding) to the target MME. If the Serving GW is not relocated, 
indirect forwarding may be set up in step 8 below. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

7. If the MME has been relocated, the target MME sends a Forward Relocation Response (Cause, Target to Source 
transparent container. Serving GW change indication, EPS Bearer Setup List, Addresses and TEIDs) message to 
the source MME. For indirect forwarding, this message includes Serving GW Address and TEIDs for indirect 
forwarding (source or target). Serving GW change indication indicates a new Serving GW has been selected. 

8. If indirect forwarding applies, the source MME sends Create Indirect Data Forwarding Tunnel Request 
(addresses and TEIDs for forwarding) to the Serving GW. If the Serving GW is relocated it includes the tunnel 
identifier to the target serving GW. 

The Serving GW responds with a Create Indirect Data Forwarding Tunnel Response (Serving GW addresses and 
TEIDs for forwarding) message to the source MME. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

9. The source MME sends a Handover Command (Target to Source transparent container. Bearers subject to 
forwarding. Bearers to Release) message to the source eNodeB. The Bearers subject to forwarding includes list 
of addresses and TEIDs allocated for forwarding. The Bearers to Release includes the list of bearers to be 
released. 
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9a. The Handover Command is constructed using the Target to Source transparent container and is sent to the UE. 
Upon reception of this message the UE will remove any EPS bearers for which it did not receive the 
corresponding EPS radio bearers in the target cell. 

10. The source eNodeB sends the eNodeB Status Transfer message to the target eNodeB via the MME(s) to convey 
the PDCP and HEN status of the E-RABs for which PDCP status preservation applies, as specified in 

TS 36.300 [5]. The source eNodeB may omit sending this message if none of the E-RABs of the UE shall be 
treated with PDCP status preservation. 

If there is an MME relocation the source MME sends this information to the target MME via the Forward Access 
Context Notification message which the target MME acknowledges. The source MME or, if the MME is 
relocated, the target MME, sends the information to the target eNodeB via the eNodeB Status Transfer message. 

1 1 . The source eNodeB should start forwarding of downlink data from the source eNodeB towards the target 
eNodeB for bearers subject to data forwarding. This may be either direct (step 11a) or indirect forwarding (step 
lib). 

12. After the UE has successfully synchronized to the target cell, it sends a Handover Confirm message to the target 
eNodeB. Downlink packets forwarded from the source eNodeB can be sent to the UE. Also, uplink packets can 
be sent from the UE, which are forwarded to the target Serving GW and on to the PDN GW. 

13. The target eNodeB sends a Handover Notify (TAl+ECGI) message to the target MME. 

14. If the MME has been relocated, the target MME sends a Forward Relocation Complete Notification () message 
to the source MME. The source MME in response sends a Forward Relocation Complete Acknowledge () 
message to the target MME. Regardless if MME has been relocated or not, a timer in source MME is started to 
supervise when resources in Source eNodeB and if the Serving GW is relocated, also resources in Source 
Serving GW shall be released. 

Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a timer if the 
target MME allocated S-GW resources for indirect forwarding. 

15. The MME sends a Modify Bearer Request (eNodeB address and TEID allocated at the target eNodeB for 
downlink traffic on Sl-U for the accepted EPS bearers, ISR Activated) message to the target Serving GW for 
each PDN connection, including the PDN connections that need to be released. If the PDN GW requested UE's 
location and/or User CSG information (determined from the UE context), the MME also includes the User 
Location Information IE and/or User CSG Information IE in this message. If the UE Time Zone has changed, the 
MME includes the UE Time Zone IE in this message. If Serving GW is not relocated but the Serving Network 
has changed or if the MME has not received any old Serving Network information from the old SGSN, the 
MME includes the Serving Network IE in this message. For the case that neither MME nor S-GW changed, if 
ISR was activated before this procedure MME should maintain ISR. The UE is informed about the ISR status in 
the Tracking Area Update procedure. If the Serving GW supports Modify Access Bearers Request procedure and 
if there is no need for the SGW to send the signalling to the PGW, the MME may send Modify Access Bearers 
Request (eNodeB address and TEID allocated at the target eNodeB for downlink traffic on S 1 U for the accepted 
EPS bearers, ISR Activated) per UE to the Serving GW to optimize the signalling. 

The MME releases the non-accepted dedicated bearers by triggering the bearer release procedure as specified in 
clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 
packet and does not send a Downlink Data Notification to the MME. 

If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are other PDN 
connections active, the MME shall handle it in the same way as if all bearers of a PDN connection have not been 
accepted. The MME releases these PDN connections by triggering the MME requested PDN disconnection 
procedure specified in clause 5.10.3. 

When the Modify Bearer Request does not indicate ISR Activated the Serving GW deletes any ISR resources by 
sending a Delete Bearer Request to the other CN node that has bearer resources on the Serving GW reserved. 

16. If the Serving GW is relocated, the target Serving GW assigns addresses and TEIDs (one per bearer) for 
downlink traffic from the PDN GW. It sends a Modify Bearer Request (Serving GW addresses for user plane and 
TEID(s), Serving Network) message per PDN connection to the PDN GW(s). The S-GW also includes User 
Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 15. 
The Serving GW also includes Serving Network IE if it is present in step 4 or step 15. The Serving GW allocates 
DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW updates its context field and returns a Modify 
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Bearer Response (Charging Id, MSISDN) message to the target Serving GW. The MSISDN is included if the 
PDN GW has it stored in its UE context. The PDN GW starts sending downUnk packets to the target GW using 
the newly received address and TEIDs. These downlink packets will use the new downlink path via the target 
Serving GW to the target eNodeB. 

If the Serving GW is not relocated, but has received the User Location Information IE and/or UE Time Zone IE 
and/or User CSG Information IE and/or Serving Network IE from the MME in step 15, the Serving GW shall 
inform the PDN GW(s) about these information that e.g. can be used for charging, by sending the message 
Modify Bearer Request (User Location Information IE, UE Time Zone IE, User CSG Information IE, Serving 
Network IE) to the PDN GW(s) concerned. A Modify Bearer Response message is sent back to the Serving GW. 

If the Serving GW is not relocated and it has not received User Location Information IE nor UE Time Zone IE 
nor User CSG Information IE nor Serving Network IE from the MME in step 15, no message is sent in this step 
and downlink packets from the Serving-GW are immediately sent on to the target eNodeB. 

17. The Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) 
message to the MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response 
(Serving GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If 
the Serving GW cannot serve the MME Request in the Modify Access Bearers Request message without S5/S8 
signalling or without corresponding Gxc signalling when PMIP is used over the S5/S8 interface, it shall respond 
to the MME with indicating that the modifications are not limited to S 1-U bearers, and the MME shall repeat its 
request using Modify Bearer Request message per PDN connection. 

If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old 
path immediately after switching the path in order to assist the reordering function in the target eNodeB. 

18. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for 
tracking area update" applies. 

The target MME knows that it is a Handover procedure that has been performed for this UE as it received the 
bearer context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source MME and target MME. 

19. When the timer started in step 14 expires the source MME sends a UE Context Release Command () message to 
the source eNodeB. The source eNodeB releases its resources related to the UE and responds with a UE Context 
Release Complete () message. When the timer started in step 14 expires and if the source MME received the 
Serving GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources 
by sending Delete Session Request (Cause, LBI, Operation Indication) messages to the Source Serving GW. The 
operation Indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall 
not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete 
Session Response () messages. If ISR has been activated before this procedure, the cause indicates to the Source 
S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete 
Bearer Request message(s) to that CN node. 

20. If indirect forwarding was used then the expiry of the timer at source MME started at step 14 triggers the source 
MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary 
resources used for indirect forwarding that were allocated at step 8. 

21. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target MME 
started at step 14 triggers the target MME to send a Delete Indirect Data Forwarding Tunnel Request message to 
the target S-GW to release temporary resources used for indirect forwarding that were allocated at step 6. 

5.5.1.2.3 S1 -based handover, Reject 

The Target eNodeB rejects the use of the Handover procedure if none of the requested bearers in the Handover Request 
message could be established. In this case no UE context is established in the target MME/eNodeB and no resources are 
allocated. Further, the Target MME rejects the handover request and clears all resource in Target eNodeB and Target 
MME if the Target eNodeB accepts the handover request but none of the default EPS bearers gets resources allocated. 
In both cases, the UE remains in the Source eNodeB/MME. 
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Figure 5.5.1.2.3-1: S1-based handover, Reject 

NOTE 1: Steps 3, 4, 7 and 8 are performed if the MME is relocated. 

NOTE 2: If the MME is not relocated Steps 5 and 6 are performed by the source MME and, in the description 
below, the source MME acts as the target MME. 

1-5. Steps 1 to 5 in the flow are identical to steps 1-5 in clause 5.5.1.2.2. 

6a. If the Target eNodeB fails to allocate any resources for any of the requested EPS bearers it sends a Handover 
Failure (Cause) message to the Target MME. The Target MME clears any reserved resources for this UE in the 
target MME. 

6b. If the Target MME receives a Handover Request Acknowledge message from the Target eNodeB but none of the 
default EPS bearers are in the EPS Bearer Setup list IE, the Target MME clears any reserved resources for this 
UE in both the Target MME and the Target eNodeB. 

7. This step is only performed for Serving GW relocation, i.e. if steps 4/4a have been performed. The Target MME 
deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving 
GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 

8. The Target MME sends the Forward Relocation Response (Cause) message to the Source MME. 

9. When the Source MME receives the Forward Relocation Response message, it sends a Handover Preparation 
Failure (Cause) message to the Source eNodeB. 



5.5.1.2.4 



S1 -based handover, Cancel 



Instead of completing the handover procedure, the source eNodeB may at any time during the handover procedure, up 
to the time when a handover command message is sent to the UE cancel the handover. 

The MME shall cancel the handover resources as defined in clause 5.5.2.5.1 for case the source RAN is eNodeB. 

5.5.2 Inter RAT handover 



5.5.2.0 



General 



During Inter RAT handover indirect forwarding may apply for the dowlink data forwarding performed as part of the 
handover. From its configuration data the MME knows whether indirect forwarding applies and it allocates a dowlink 
data forwarding path on a Serving GWs for indirect forwarding. From its configuration data the S4 SGSN knows 
whether indirect forwarding applies and it allocates dowlink data forwarding paths on Serving GWs for indirect 
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forwarding. It is configured on MME and S4 SGSN whether indirect dowlink data forwarding does not apply, applies 
always or applies only for inter PLMN inter RAT handovers. 



5.5.2.1 



E-UTRAN to UTRAN lu mode Inter RAT handover 



5.5.2.1.1 

Pre-conditions: 



General 



- The UE is in ECM-CONNECTED state (E-UTRAN mode). 

If emergency bearer services are ongoing for an UE, handover to the target RNC is performed independent of the 
Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution phase, if the 
handover is to a restricted area and if so SGSN deactivate the non-emergency PDF context as specified in 
TS 23.060 [7], clause 9.2.4.2. 



5.5.2.1.2 



Preparation phase 
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Figure 5.5.2.1.2-1 : E-UTRAN to UTRAN lu mode Inter RAT HO, preparation phase 

1. The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN lu mode. At 
this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and source 
eNodeB, GTP tunnel(s) between source eNodeB, Serving GW and PDN GW. 

If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to a 
UTRAN cell that is not IMS voice capable. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this specification. 

2. The source eNodeB sends a Handover Required (SlAP Cause, Target RNC Identifier, CSG ID, CSG access 
mode. Source to Target Transparent Container) message to the source MME to request the CN to establish 
resources in the target RNC, target SGSN and the Serving GW. The bearers that will be subject to data 
forwarding (if any) are identified by the target SGSN in a later step (see step 7 below). When the target cell is a 
CSG cell or a hybrid cell, the source eNodeB shall include the CSG ID of the target cell. If the target cell is a 
hybrid cell, the CSG access mode shall be indicated. 

3. The source MME determines from the 'Target RNC Identifier' IE that the type of handover is IRAT Handover to 
UTRAN lu mode. The Source MME initiates the Handover resource allocation procedure by sending a Forward 
Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, PDN 
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Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane. Source to 
Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG Information 
Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network) message to the target SGSN. 
The information ISR Supported is indicated if the source MME and associated Serving GW are capable to 
activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for 
the UE when this SGSN is serving the target identified by the Target Identification. This message includes all 
PDN Connections active in the source system and for each PDN Connection includes the associated APN, the 
address and the uplink Tunnel endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer 
Contexts. RAN Cause indicates the SI AP Cause as received from source eNodeB. The old Serving Network is 
sent to target MME to support the target MME to resolve if Serving Network is changed. 

The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided 
by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and 
the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause. 

The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or 
hybrid cell. When the target cell is a hybrid cell, the CSG Membership Indication indicating whether the UE is a 
CSG member shall be included in the Forward Relocation Request message. 

The target SGSN maps the EPS bearers to PDP contexts 1-to-l and maps the EPS Bearer QoS parameter values 
of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E 

Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN. 

The MM context contains security related information, e.g. supported ciphering algorithms as described in 
TS 29.274 [43]. HandHng of security keys is described in TS 33.401 [41]. 

The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer 
context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction 
value. 

4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW 
is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving 
GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier 
for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) 
for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol 
Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over 
S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. 

The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as 
provided in step 7 of the execution phase, the EPS Bearer contexts which cannot be established. 

4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target SGSN. 

5. The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the 
message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e. 
IK and allowed Integrity Protection algorithms). Encryption information (i.e. CK and allowed Ciphering 
algorithms), RAB to be setup list, CSG ID, CSG Membership Indication, Source RNC to Target RNC 
Transparent Container, Service Handover related information). If the Access Restriction is present in the MM 
context, the Service Handover related information shall be included by the target SGSN for the Relocation 
Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by 
the Access Restriction. 

For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB 
parameters. Transport Layer Address, and lu Transport Association. The RAB ID information element contains 
the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer 
Address is the Serving GW Address for user plane (if Direct Tunnel is used) or the SGSN Address for user plane 
(if Direct Tunnel is not used), and the lu Transport Association corresponds to the uplink Tunnel Endpoint 
Identifier Data in Serving GW or SGSN respectively. 

Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new 
RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. 
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Information that is required to be sent to the UE (either in the Relocation Command message or after the 
handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the 
target RNC to the UE via the transparent container. More details are described in TS 33.401 [41]. 

The Target SGSN shall include the CSG ID and CSG Membership Indication when provided by the source 
MME in the Forward Relocation Request message. 

In the target RNC radio and lu user plane resources are reserved for the accepted RABs. Cause indicates the 
RAN Cause as received from source MME. The Source RNC to Target RNC Transparent Container includes the 
value from the Source to Target Transparent Container received from the source eNodeB. 

If the target cell is a CSG cell, the target RNC shall verify the CSG ID provided by the target SGSN, and reject 
the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target cell is in 
hybrid mode, the target RNC may use the CSG Membership Indication to perform differentiated treatment for 
CSG and non-CSG members. 

5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message 
Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container, RABs setup list, RABs 
failed to setup list). 

Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive 
downlink GTP PDUs from the Serving GW, or Target SGSN if Direct Tunnel is not used, for the accepted 
RABs. 

Each RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for user data, 
and the lu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. 

Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN and the UE. 
These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the 
completion of the routing area update (RAU) procedure. 

6. If Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel is used the target SGSN sends a 
Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and TEID(s) for DL data 
forwarding) to the Serving GW. If Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel 
is not used, then the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (SGSN 
Address and TEID(s) for DL data forwarding) to the Serving GW. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) 
and Serving GW DL TEID(s) for data forwarding) message to the target SGSN. 

7. The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for 
Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, Cause, RAB Setup 
Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data Forwarding, 
Serving GW change indication) to the source MME. Serving GW change indication indicates a new Serving GW 
has been selected. The Target to Source Transparent Container contains the value from the Target RNC to 
Source RNC Transparent Container received from the target RNC. 

The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint 
for data forwarding in target system, and it is set as follows: 

If 'Direct Forwarding' applies, or if 'Indirect Forwarding' and no relocation of Serving GW apply and Direct 
Tunnel is used, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the 
addresses and GTP-U tunnel endpoint parameters to the Target RNC received in step 5a. 

If 'Indirect Forwarding' and relocation of Serving GW apply, then the IE 'Address(es) and TEID(s) for User 
Traffic Data Forwarding' contains the addresses and DL GTP-U tunnel endpoint parameters to the Serving 
GW received in step 6. This is independent from using Direct Tunnel or not. 

If 'Indirect Forwarding' applies and Direct Tunnel is not used and relocation of Serving GW does not apply, 
then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel 
endpoint parameters to the Target SGSN. 
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8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel 
Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)), EPS Bearer ID(s)) to the Serving 
GW used for indirect forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding parameters by sending the message Create Indirect Data Forwarding 
Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW 
doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) 
and TEID(s) will not be included in the message. 



5.5.2.1.3 
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NOTE: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF 
interaction in the case of PMIP-based S5/S8. Steps 8 and 8a concern GTP based S5/S8 

The source eNodeB continues to receive downlink and uplink user plane PDUs. 

1 . The source MME completes the preparation phase towards source eNodeB by sending the message Handover 
Command (Target to Source Transparent Container, E-RABs to Release List, Bearers Subject to Data 
Forwarding List). The "Bearers Subject to Data forwarding list" IE may be included in the message and it shall 
be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from target side in the preparation 
phase (Step 7 of the preparation phase) when 'Direct Forwarding' applies, or the parameters received in Step 8a 
of the preparation phase when 'Indirect Forwarding' applies. 

The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided 
by source MME and or/ target SGSN in the preparation phase. 

2. The source eNodeB will give a command to the UE to handover to the target access network via the message HO 
from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that 
the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are 
described in TS 36.300 [5]. 

Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, 
the UE shall associate its bearer IDs to the respective RABs based on the relation with the NSAPI and shall 
suspend the uplink transmission of the user plane data. 

3. Void. 

4. The UE moves to the target UTRAN lu (3G) system and executes the handover according to the parameters 
provided in the message delivered in step 2. The procedure is the same as in step 6 and 8 in clause 5.2.2.2 in 
TS 43. 129 [8] with the additional function of association of the received RABs and existing Bearer Id related to 
the particular NSAPI. 

The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in 
the target RNC. 

5. When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC shall send the 
Relocation Complete message to the target SGSN. The purpose of the Relocation Complete procedure is to 
indicate by the target RNC the completion of the relocation from the source E-UTRAN to the RNC. After the 
reception of the Relocation Complete message the target SGSN shall be prepared to receive data from the target 
RNC. Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving GW. 

6. Then the target SGSN knows that the UE has arrived to the target side and target SGSN informs the source 
MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. 
If indicated, ISR Activated indicates to the source MME that it shall maintain the UE's context and that it shall 
activate ISR, which is only possible when the S-GW is not changed. The source MME will also acknowledge 
that information. A timer in source MME is started to supervise when resources in Source eNodeB and Source 
Serving GW (for Serving GW relocation) shall be released. 

When the timer expires and ISR Activated is not indicated by the target SGSN the source MME releases all 
bearer resources of the UE. If Serving GW change is indicated and this timer expires the source MME deletes 
the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the 
Source Serving GW. The operation Indication flag is not set, that indicates to the Source Serving GW that the 
Source Serving GW shall not initiate a delete procedure towards the PDN GW. If ISR has been activated before 
this procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the bearer resources on 
the other old CN node by sending Delete Bearer Request message(s) to that CN node. 

Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the 
target SGSN allocated S-GW resources for indirect forwarding. 

7. The target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the target SGSN is now responsible for all the EPS Bearer 
Contexts the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel 
Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and 
TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is not used) or RNC Address(es) and 
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TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is used) and RAT type, ISR Activated) 
per PDN connection. If the PDN GW requested UE's location and/or User CSG information (determined from 
the UE context), the SGSN also includes the User Location Information IE and/or User CSG Information IE in 
this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. If 
Serving GW is not relocated but the Serving Network has changed or if the SGSN has not received any old 
Serving Network information from the old MME, the SGSN includes the new Serving Network IE in this 
message. In network sharing scenarios Serving Network denotes the serving core network. If indicated, the 
information ISR Activated indicates that ISR is activated, which is only possible when the S-GW is not changed. 
When the Modify Bearer Request does not indicate ISR Activated and S-GW is not changed,, the S-GW deletes 
any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the 
S-GW reserved. 

The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context deactivation 
procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 
packet and does not send a Downlink Data Notification to the SGSN. 

8. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW(s) 
the change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by 
sending the message Modify Bearer Request per PDN connection. The S-GW also includes User Location 
Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 7. Serving 
Network should be included if it is received in step 7 or in step 4 in clause 5.5.2.1.2. For Serving GW relocation, 
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge 
the request with the message Modify Bearer Response. In the case of Serving GW relocation, the PDN GW 
updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the 
Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. 

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the target SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options). At this 
stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC, target SGSN if 
Direct Tunnel is not used. Serving GW (for Serving GW relocation this will be the Target Serving GW) and 
PDN GW. 

If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old 
path immediately after switching the path. 

10. When the UE recognises that its current Routing Area is not registered with the network, or when the UE's TIN 
indicates "GUTI", the UE initiates a Routing Area Update procedure with the target SGSN informing it that the 
UE is located in a new routing area. It is RAN functionality to provide the PMM-CONNECTED UE with 
Routing Area information. 

The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure, 
specifically it excludes the context transfer procedures between source MME and target SGSN. 

1 1 . When the timer started at step 6 expires, the source MME sends a Release Resources message to the Source 
eNodeB. The Source eNodeB releases its resources related to the UE. 

When the timer started in step 6 expires and if the source MME received the Serving GW change indication in 
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session 
Request (Cause, Operation Indication) messages to the Source Serving GW. The operation indication flag is not 
set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure 
towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response (Cause) messages. 
If ISR has been activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW 
shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that 
CN node. 

12. If indirect forwarding was used then the expiry of the timer at source MME started at step 6 triggers the source 
MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary 
resources used for indirect forwarding. 
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13. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN 
started at step 6 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to 
the target S-GW to release temporary resources used for indirect forwarding. 



5.5.2.1.4 



E-UTRAN to UTRAN lu mode Inter RAT handover Reject 



The Target RNC may reject the use of the Handover procedure if none of the requested RABs in the Relocation Request 
message could be established. In this case no UE context is established in the target SGSN/RNC and no resources are 
allocated. The UE remains in the Source eNodeB/MME. 
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Figure 5.5.2.1.4-1 : E-UTRAN to UTRAN lu mode Inter RAT HO reject 

1. The Step 1 to 5 in the flow are identical to the ones in clause 5.5.2.1.2. 

6. If the Target RNC fails to allocate any resources for any of the requested RABs it sends a Relocation Failure 
(Cause) message to the Target SGSN. When the Target SGSN receives the Relocation Failure message from 
Target RNC the Target SGSN clears any reserved resources for this UE. 

7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target SGSN 
deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving 
GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 

8. The Target SGSN sends the Forward Relocation Response (Cause) message to the Source MME. 

9. When the Source MME receives the Forward Relocation Response message it send a Handover Preparation 
Failure (Cause) message to the Source eNodeB. 



5.5.2.2 



UTRAN lu mode to E-UTRAN Inter RAT handover 



5.5.2.2.1 



General 



The UTRAN lu mode to E-UTRAN Inter RAT handover procedure takes place when the network decides to perform a 
handover. The decision to perform PS handover from UTRAN lu mode to E-UTRAN is taken by the network based on 
radio condition measurements reported by the UE to the UTRAN RNC. 

If emergency bearer services are ongoing for the UE, the MME checks as part of the Tracking Area Update in the 
execution phase, if the handover is to a restricted area and if so MME releases the non-emergency bearers as specified 
in clause 5.10.3. 
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Figure 5.5.2.2.2-1 : UTRAN lu mode to E-UTRAN Inter RAT HO, preparation phase 

1. The source RNC decides to initiate an Inter-RAT handover to the E-UTRAN. At this point both uplink and 
downlink user data is transmitted via the following: Bearers between UE and source RNC, GTP tunnel(s) 
between source RNC, source SGSN (only if Direct Tunnel is not used). Serving GW and PDN GW. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this specification. 

2. The source RNC sends a Relocation Required (Cause, Target eNodeB Identifier, CSG ID, CSG access mode. 
Source RNC Identifier, Source RNC to Target RNC Transparent Container) message to the source SGSN to 
request the CN to establish resources in the target eNodeB, Target MME and the Serving GW. The bearers that 
will be subject to data forwarding (if any) are identified by the target MME in a later step (see step 7 below). 
When the target cell is a CSG cell or a hybrid cell, the source RNC shall include the CSG ID of the target cell. If 
the target cell is a hybrid cell, the CSG access mode shall be indicated. 

3. The source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT 
Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending 
Forward Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, 
PDN Connections, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane. 
Source to Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG 
Information Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network) message to the 
target MME. This message includes all EPS Bearer contexts corresponding to all the bearers established in the 
source system and the uplink Tunnel endpoint parameters of the Serving GW. If the information ISR Supported 
is indicated, this indicates that the source SGSN and associated Serving GW are capable to activate ISR for the 
UE. When ISR is activated the message should be sent to the MME that maintains ISR for the UE when this 
MME is serving the target identified by the Target Identification. RAN Cause indicates the Cause as received 
from source RNC. The Source to Target Transparent Container contains the value from the Source RNC to 
Target RNC Transparent Container received from the Source RNC. The old Serving Network is sent to target 
MME to support the target MME to resolve if Serving Network is changed. 

The source SGSN shall perform access control by checking the UE's CSG subscription when CSG ID is 
provided by the source RNC. If there is no subscription data for this CSG ID or the CSG subscription is expired, 
and the target cell is a CSG cell, the source SGSN shall reject the handover with an appropriate cause. 
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The source SGSN includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or 
hybrid cell. When the target cell is a hybrid cell, the CSG Membership Indication indicating whether the UE is a 
CSG member shall be included in the Forward Relocation Request message. 

This message includes all PDN Connections active in the source system and for each PDN Connection includes 
the associated APN, the address and the uplink tunnel endpoint parameters of the Serving GW for control plane, 
and a list of EPS Bearer Contexts. 

Prioritization of EPS Bearer Contexts is performed by the target core network node. 

The MM context contains security related information, e.g. UE Network capabilities and used UMTS integrity 
and ciphering algorithm(s) as well as keys, as described in clause 5.7.2 (Information Storage for MME). 

The target MME selects the NAS ciphering and integrity algorithms to use. These algorithms will be sent 
transparently from the target eNodeB to the UE in the Target to Source Transparent Container (EPC part). 

The MME establishes the EPS bearer(s) in the prioritized order. The MME deactivates, as provided in step 8 of 
the execution phase, the EPS bearers which cannot be established. 

The target MME shall determine the Maximum APN restriction based on the APN Restriction of each bearer 
context received in the Forward Relocation Request, and shall subsequently store the new Maximum APN 
restriction value. 

4. The target MME determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW 
is to be relocated, the target MME selects the target Serving GW as described under clause 4.3.8.2 on "Serving 
GW selection function". The target MME sends a Create Session Request message (IMSI, MME Address and 
TEID, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, PDN GW 
address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address for control plane, and PDN 
GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the 
target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used 
over S5/S8 interface. 

4a. The target Serving GW allocates its local resources and returns them in a Create Session Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target MME. 

5. The target MME requests the target eNodeB to establish the bearer(s) by sending the message Handover Request 
(UE Identifier, SlAP Cause, KgNB^ allowed AS Integrity Protection and Ciphering algorithm(s), NAS Security 
Parameters to E-UTRAN, EPS Bearers to be setup list, CSG ID, CSG Membership Indication, Source to Target 
Transparent Container). The NAS Security Parameters to E-UTRAN includes the NAS Integrity Protection and 
Ciphering algorithm(s), eKSI and NONCEmme are targeted for the UE. SlAP Cause indicates the RAN Cause 
as received from source SGSN. The Source to Target Transparent Container contains the value from the RAN 
Transparent Container received from the source SGSN. 

NOTE 2: The target MME derives K'asme from CK and IK in the MM context and associates it with eKSI, as 

described in TS 33.401 [41] and selects NAS Integrity Protection and Ciphering algorithm(s). The MME 
and UE derive the NAS keys and KeNB from K'asme- If the MME shares an EPS security association with 
the UE, the MME may activate this native EPS security context by initiating a NAS SMC procedure after 
having completed the handover procedure. 

For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as 
ID, bearer parameters. Transport Layer Address, "Data forwarding not possible" indication, and S 1 Transport 
Association. The target MME ignores any Activity Status Indicator within an EPS Bearer Context and requests 
the target eNodeB to allocate resources for all EPS Bearer Contexts received from the source side. The Transport 
Layer Address is the Serving GW Address for user data, and the S 1 Transport Association corresponds to the 
uplink Tunnel Endpoint Identifier Data. "Data forwarding not possible" indication shall be included if the target 
MME decides the corresponding bearer will not be subject to data forwarding. 

The target MME shall include the CSG ID and CSG Membership Indication when provided by the source SGSN 
in the Handover Request message. 

The information about the selected NAS ciphering and integrity protection algorithm(s), KSI and NONCEmme 
will be sent transparently from the target eNodeB to the UE in the Target to Source Transparent Container, and 
in the message UTRAN HO Command from source RNC to the UE. This will then allow data transfer to 
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continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) 
procedure. More details are described in TS 33.401 [41]. 

If the target cell is a CSG cell, the target eNodeB shall verify the CSG ID provided by the target MME, and 
reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target 
eNodeB is in hybrid mode, it may use the CSG Membership Status to perform differentiated treatment for CSG 
and non-CSG members. 

5a. The target eNodeB allocates the requested resources and returns the applicable parameters to the target MME in 
the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list, 
EPS Bearers failed to setup list). The target eNodeB shall ignore it if the number of radio bearers in the Source to 
Target Transparent container does not comply with the number of bearers requested by the MME and allocate 
bearers as requested by the MME. Upon sending the Handover Request Acknowledge message the target 
eNodeB shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS bearers. 

The target eNodeB selects AS integrity and ciphering algorithm(s). In addition to the information provided by 
the MME (eKSI, NAS Integrity Protection and Ciphering algorithm(s) and NONCEmme), the target eNodeB 
inserts AS integrity and ciphering algorithm(s) into the UTRAN RRC message, which is contained in the Target 
to Source Transparent Container. 

6. If Indirect Forwarding' and relocation of Serving GW apply the target MME sends a Create Indirect Data 
Forwarding Tunnel Request message (Target eNodeB Address, TEID(s) for DL data forwarding) to the Serving 
GW. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) 
and Serving GW DL TEID(s) for data forwarding) message to the target MME. 

7. The target MME sends the message Forward Relocation Response (Cause, List of Set Up RABs, EPS Bearers 
setup list, MME Tunnel Endpoint Identifier for Control Plane, RAN Cause, MME Address for control plane. 
Target to Source Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving GW change 
indication) to the source SGSN. Serving GW change indication indicates whether a new Serving GW has been 
selected. The Target to Source Transparent Container includes the value from the Target to Source Transparent 
Container received from the target eNodeB. 

The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint 
for data forwarding in target system, and it is set as follows. If 'Direct Forwarding' or if 'Indirect Forwarding' but 
no relocation of Serving GW applies, then the lEs 'Address(es) and TEID(s) for Data Forwarding' contains the 
forwarding DL GTP-U tunnel endpoint parameters to the eNodeB received in step 5a. 

If 'Indirect Forwarding' and relocation of Serving GW apply the lEs 'Address(es) and TEID(s) for Data 
Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target eNodeB or to the forwarding 
Serving GW received in step 6a. 

8. If "Indirect Forwarding" applies, the source SGSN shall send the message Create Indirect Data Forwarding 
Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for 
indirect forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Indirect Data 
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for data forwarding). If the Serving 
GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW 
Address(es) and TEID(s) will not be included in the message. 
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Figure 5.5.2.2.3-1 : UTRAN lu mode to E-UTRAN Inter RAT HO, execution phase 

For a PMIP -based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF 
interaction in the case of PMIP -based S5/S8. Steps 9 and 9a concern GTP based S5/S8. 



The source RNC continues to receive downlink and upHnk user plane PDUs. 

1. The source SGSN completes the preparation phase towards source RNC by sending the message Relocation 
Command (Target RNC to Source RNC Transparent Container, RABs to be Released List, RABs Subject to 
Data Forwarding List). The "RABs to be Released list" IE will be the list of all NSAPIs (RAB Ids) for which a 
Bearer was not established in Target eNodeB. The "RABs Subject to Data forwarding list" IE may be included in 
the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from 
target side in step 7 of the preparation phase when 'Direct Forwarding' applies. If 'Indirect Forwarding' is 
applicable and Direct Tunnel is used the "RABs Subject to Data Forwarding List" IE includes the parameters 
received in Step 8a of the preparation phase. If 'Indirect Forwarding' is applicable and Direct Tunnel is not used 
the "RABs Subject to Data Forwarding List" IE includes the source SGSN address(es) and TEID(s) allocated for 
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indirect data forwarding by Source SGSN. The Target RNC to Source RNC Transparent Container contains the 
value from the Target to Source Transparent Container received from the target MME. 

2. The source RNC will command to the UE to handover to the target eNodeB via the message HO from UTRAN 
Command. The access network specific message to UE includes a transparent container including radio aspect 
parameters that the target eNodeB has set-up in the preparation phase. 

The source RNC may initiate data forwarding for the indicated RABs/EPS Bearer contexts specified in the 
"RABs Subject to Data Forwarding List". The data forwarding may go directly to target eNodeB, or alternatively 
go via the Serving GW if so decided by source SGSN and/or target MME in the preparation phase. 

Upon the reception of the HO from UTRAN Command message containing the Relocation Command message, 
the UE shall associate its RAB IDs to the respective bearers ID based on the relation with the NSAPI and shall 
suspend the uplink transmission of the user plane data. 

3. Void. 

4. The UE moves to the E-UTRAN and performs access procedures toward target eNodeB. 

5. When the UE has got access to target eNodeB it sends the message HO to E-UTRAN Complete. 

The UE shall implicitly derive the EPS bearers for which an E-RAB was not established from the HO from 
UTRAN Command and deactivate them locally without an explicit NAS message at this step. 

6. When the UE has successfully accessed the target eNodeB, the target eNodeB informs the target MME by 
sending the message Handover Notify (TAIh-ECGI). 

7. Then the target MME knows that the UE has arrived to the target side and target MME informs the source SGSN 
by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. If ISR 
Activated is indicated, this indicates to the source SGSN that it shall maintain the UE's contexts and activate 
ISR, which is only possible when the S-GW is not changed. The source SGSN shall also acknowledge that 
information. A timer in source SGSN is started to supervise when resources in the in Source RNC and Source 
Serving GW (for Serving GW relocation) shall be released 

Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a timer if the 
target MME applies indirect forwarding. 

8. The target MME will now complete the Inter-RAT Handover procedure by informing the Serving GW (for 
Serving GW relocation this will be the Target Serving GW) that the target MME is now responsible for all the 
bearers the UE have established. This is performed in the message Modify Bearer Request (Cause, MME Tunnel 
Endpoint Identifier for Control Plane, EPS Bearer ID, MME Address for Control Plane, eNodeB Address(es) 
and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection. 
If the PDN GW requested UE's location and/or User CSG information (determined from the UE context), the 
MME also includes the User Location Information IE and/or User CSG Information IE in this message. If the 
UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If Serving GW is not 
relocated but the Serving Network has changed, the MME includes the new Serving Network IE in this message. 
If indicated, the information ISR Activated indicates that ISR is activated, which is only possible when the 
S-GW was not changed. When the Modify Bearer Request does not indicate ISR Activated and S-GW is not 
changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has 
bearer resources on the S-GW reserved. 

The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in 

clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 

packet and does not send a Downlink Data Notification to the MME. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the 
change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by sending 
the message Modify Bearer Request per PDN connection. The S-GW also includes User Location Information 
IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 8. Serving Network 
should be included if it is received in step 8 or in step 4 in clause 5.5.2.2.2. For Serving GW relocation, the 
Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge the 
request with the message Modify Bearer Response. In the case of Serving GW relocation, the PDN GW updates 
its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the Serving 
GW. The MSISDN is included if the PDN GW has it stored in its UE context. 
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If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 

10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the target MME via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options). At this 
stage the user plane path is established for all bearers between the UE, target eNodeB, Serving GW (for Serving 
GW relocation this will be the Target Serving GW) and PDN GW. 

If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old 
path immediately after switching the path in order to assist the reordering function in the target eNodeB. 

1 1 . The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for 
tracking area update" applies. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. 

12. When the timer started in step 7 expires the source SGSN will clean-up all its resources towards source RNC by 
sending the lu Release Command to the RNC. When there is no longer any need for the RNC to forward data, 
the source RNC responds with an lu Release Complete message. 

When the timer started in step 7 expires and if the source SGSN received the Serving GW change indication in 
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session 
Request (Cause, Operation Indication) messages to the Source Serving GW. The operation Indication flag is not 
set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure 
towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response (Cause) messages. 
If ISR has been activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW 
shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that 
CN node. 

13. If indirect forwarding was used then the expiry of the timer at source SGSN started at step 7 triggers the source 
SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary 
resources used for indirect forwarding. 

14. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target MME 
started at step 7 triggers the target MME to send a Delete Indirect Data Forwarding Tunnel Request message to 
the target S-GW to release temporary resources used for indirect forwarding. 

5.5.2.2.4 UTRAN lu mode to E-UTRAN Inter RAT handover reject 

The Target eNodeB may reject the use of the Handover procedure if none of the requested EPS bearers in the Handover 
Request message could be established. In this case no UE context is established in the target MME/eNodeB and no 
resources are allocated. The UE remains in the Source RNC/SGSN. 
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Figure 5.5.2.2.4-1 : UTRAN lu mode to E-UTRAN Inter RAT HO reject 

1. Steps 1 to 5 in the flow are identical to the ones in clause 5.5.2.2.2. 

6. If the Target eNodeB fails to allocate any resources for any of the requested EPS Bearers it sends a Handover 
Failure (Cause) message to the Target MME. When the Target MME receives the Handover Failure message 
from Target eNodeB the Target MME clears any reserved resources for this UE. 

7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target MME 
deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving 
GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 

8. The Target MME sends the Forward Relocation Response (Cause) message to the Source SGSN. 

9. When the Source SGSN receives the Forward Relocation Response message it send a Relocation Preparation 
Failure (Cause) message to the Source RNC. 



5.5.2.3 



E-UTRAN to GERAN A/Gb mode Inter RAT handover 



5.5.2.3.1 General 

The procedure is based on Packet-switched handover for GERAN A/Gb mode defined in TS 43.129 [8]. 
Pre-conditions: 

- The UE is in ECM-CONNECTED state (E-UTRAN mode); 

The BSS must support PFM, Packet Flow Management, procedures. 
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Figure 5.5.2.3.2-1 : E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase 

1 . The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. At 
this point both upUnk and downlink user data is transmitted via the following: Bearer(s) between UE and Source 
eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW. 

If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to GERAN. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this specification 

2. The source eNodeB sends a Handover Required (SI AP Cause, Target System Identifier, Source to Target 
Transparent Container) message to the Source MME to request the CN to establish resources in the Target BSS, 
Target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by 
the target SGSN in a later step (see step 7 below). 

The 'Target System Identifier' IE contains the identity of the target global cell Id. 

3. The Source MME determines from the 'Target System Identifier' IE that the type of handover is IRAT Handover 
to GERAN A/Gb mode. The Source MME initiates the Handover resource allocation procedure by sending a 
Forward Relocation Request (IMSI, Target Identification (shall be set to "empty"), MM Context, PDN 
Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane. Source to 
Target Transparent Container, Packet Flow ID, XID parameters (if available). Target Cell Identification, MS 
Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, 
ISR Supported, RAN Cause, Serving Network) message to the target SGSN. If the information ISR Supported is 
indicated, this indicates that the source MME and associated Serving GW are capable to activate ISR for the UE. 
When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN 
is serving the target identified by the Target Identification. This message includes all PDN Connections active in 
the source system and for each PDN Connection includes the associated APN, the address and the uplink Tunnel 
endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts. The old Serving 
Network is sent to target MME to support the target MME to resolve if Serving Network is changed. In network 
sharing scenarios Serving Network denotes the serving core network. 

The target SGSN maps the EPS bearers to PDP contexts 1-to-l and maps the EPS Bearer QoS parameter values 
of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E. 

Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN. 
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If the Source MME supports IRAT Handover to GERAN A/Gb procedure it has to allocate a valid PFI during 
the bearer activation procedure. RAN Cause indicates the SlAP Cause as received from the source eNodeB. The 
Source to Target Transparent Container includes the value from the Source to Target Transparent Container 
received from the source eNodeB. 

The MM context contains security related information, e.g. supported ciphering algorithms, as described in 
TS 29.274 [43]. HandHng of security keys is described in TS 33.401 [41]. 

The target SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the target 
SGSN to the UE in the NAS container for Handover (part of the Target to Source Transparent Container). The 
lOV-UI parameter, generated in the target SGSN, is used as input to the ciphering procedure and it will also be 
transferred transparently from the target SGSN to the UE in the NAS container for Handover. More details are 
described in TS 33.401 [41]. 

When the target SGSN receives the Forward Relocation Request message the required EPS Bearer, MM, 
SNDCP and LLC contexts are established and a new P-TMSI is allocated for the UE. When this message is 
received by the target SGSN, it begins the process of establishing PFCs for all EPS Bearer contexts. 

When the target SGSN receives the Forward Relocation Request message it extracts from the EPS Bearer 
Contexts the NSAPIs and S APIs and PFIs to be used in the target SGSN. If for a given EPS Bearer Context the 
target SGSN does not receive a PFI from the source MME, it shall not request the target BSS to allocate TBF 
resources corresponding to that EPS Bearer Context. If none of the EPS Bearer Contexts forwarded from the 
source MME has a valid PFI allocated the target SGSN shall consider this as a failure case and the request for 
Handover shall be rejected. 

If when an S API and PFI was available at the source MME but the target SGSN does not support the same SAPI 
and PFI for a certain NSAPI as the source MME, the target SGSN shall continue the Handover procedure only 
for those NSAPIs for which it can support the same PFI and SAPI as the source MME. All EPS Bearer contexts 
for which no resources are allocated by the target SGSN or for which it cannot support the same SAPI and PFI 
(i.e. the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained 
and the related SAPIs and PFIs are kept. These EPS Bearer contexts may be modified or deactivated by the 
target SGSN via explicit SM procedures upon RAU procedure. 

The source MME shall indicate the current XID parameter settings if available (i.e. those XID parameters 
received during a previous IRAT Handover procedure) to the target SGSN. If the target SGSN can accept all 
XID parameters as indicated by the source MME, the target SGSN shall create a NAS container for Handover 
indicating 'Reset to the old XID parameters'. Otherwise, if the target SGSN cannot accept all XID parameters 
indicated by the source MME or if no XID parameters were indicated by the source MME, the target SGSN shall 
create a NAS container for Handover indicating Reset (i.e. reset to default parameters). 

The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer 
context received in the Forward Relocation Request, and shall subsequently store the new Maximum APN 
restriction value. 

4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW 
is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving 
GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier 
for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) 
for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol 
Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over 
S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. 

4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target SGSN. 

5. The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as 
provided in step 9 of the execution phase, the EPS Bearer contexts which cannot be established. 

The Target SGSN requests the Target BSS to establish the necessary resources (PFCs) by sending the message 
PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, PFCs to be set-up list. Source RNC to 
Target BSS Transparent Container and NAS container for handover). The target SGSN shall not request 
resources for which the Activity Status Indicator within a EPS Bearer Context indicates that no active bearer 
exists on the source side for that PDP context. The Cause indicates the RAN Cause as received from the source 
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MME. The Source RNC to Target BSS Transparent Container contains the value from the Source to Target 
Transparent Container received from the source MME. All EPS Bearer Contexts indicate active status because 
E-UTRAN does not support selective RAB handling. 

Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio 
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. 
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS 
allocates TBFs for each PFC that it can accommodate. 

The target BSS shall prepare the 'Target to Source Transparent Container' which contains a PS Handover 
Command including the EPC part (NAS container for Handover) and the RN part (Handover Radio Resources). 

5a. The Target BSS allocates the requested resources and returns the applicable parameters to the Target SGSN in 
the message PS Handover Request Acknowledge (Local TLLI, List of set-up PFCs, Target BSS to Source RNC 
Transparent Container, Cause). Upon sending the PS Handover Request Acknowledge message the target BSS 
shall be prepared to receive downlink LLC PDUs from the target SGSN for the accepted PFCs. 

Any EPS Bearer contexts for which a PFC was not established are maintained in the target SGSN and the related 
SAPIs and PFIs are kept. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM 
procedures upon the completion of the routing area update (RAU) procedure. 

6. If indirect forwarding and relocation of Serving GW applies the target SGSN sends a Create Indirect Data 
Forwarding Tunnel Request message (Target SGSN Address(es) and TEID(s) for DL data forwarding) to the 
Serving GW used for indirect packet forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL 
Address(es) and TEID(s) for data forwarding) message to the target SGSN. 

7. The Target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier 
for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, RAN Cause, List 
of set-up PFIs, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to 
the Source MME. Serving GW change indication indicates a new Serving GW has been selected. RAN Cause 
indicates the Cause as received from the target BSS. The Target to Source Transparent Container includes the 
value from the Target BSS to Source RNC Transparent Container received from the target BSS. 

If 'Indirect Forwarding' and relocation of Serving GW applies, then the lEs 'Address(es) and TEID(s) for User 
Traffic Data Forwarding' contain the DL GTP-U tunnel endpoint parameters received in step 6a. Otherwise the 
lEs 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint 
parameters to the Target SGSN. 

The target SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064 [23] for an SGSN 
originated Reset or 'Reset to the old XID parameters'. 

8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel 
Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for indirect 
packet forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Indirect Data 
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the 
Serving GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW 
Address(es) and TEID(s) will not be included in the message. 
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Figure 5.5.2.3.3-1 : E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase 

NOTE 1: For a PMIP -based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF 
interaction in the case of PMIP-based S5/S8. Steps 10 and 10a concern GTP based S5/S8 

The source eNodeB continues to receive downlink and uplink user plane PDUs. 

1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover 
Command (Target to Source Transparent Container (PS Handover Command with RN part and EPC part), 
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E-RABs to Release List, Bearers Subject to Data Forwarding List), SlAP Cause. The "Bearers Subject to Data 
forwarding list" may be included in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic 
data forwarding' received from target side in the preparation phase (Step 7 of the preparation phase for Direct 
Forwarding, else parameters received in Step 8a of the preparation phase). SlAP Cause indicates the RAN Cause 
as received from the target SGSN. 

Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding may go directly i.e. to target SGSN or alternatively go via the Serving GW if so 
decided by source MME and/or target SGSN in the preparation phase. 

2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message 
HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters 
that the Target BSS has set-up in the preparation phase (RN part). This message also includes the XID and lOV- 
UI parameters received from the Target SGSN (EPC part). 

Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, 
the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI and shall 
suspend the uplink transmission of the user plane data. 

3. Void. 

4. The UE moves to the Target GERAN A/Gb (2G) system and performs executes the handover according to the 
parameters provided in the message delivered in step 2. The procedure is the same as in step 6 in clause 5.3.2.2 
in TS 43. 129 [8] with the additional function of association of the received PFI and existing Bearer Id related to 
the particular NSAPI. 

5. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 4, the 
UE processes the NAS container and then sends one XID response message to the target SGSN via target BSS. 
The UE sends this message immediately after receiving the Packet Physical Information message containing the 
timing advance or, in the synchronised network case, immediately if the PS Handover Access message is not 
required to be sent. 

Upon sending the XID Response message, the UE shall resume the user data transfer only for those NSAPIs for 
which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM, for which radio 
resources were not allocated in the target cell, the MS may request for radio resources using the legacy 
procedures. 

If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in 
the HO from E-UTRAN Command message, and to avoid collision cases the mobile station may avoid triggering 
XID negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any case 
the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but wait for the 
SGSN to do so (see step 12a). 

This step is the same as specified in clause 5.3.2.2 in TS 43.129 [8]. 

6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to the Target 
BSS, the Target BSS informs the Target SGSN by sending the message PS Handover Complete (IMSI, and 
Local TLLI, Request for Inter RAT Handover Info). The target BSS that supports inter-RAT PS handover to 
UTRAN shall, when the INTER RAT HANDOVER INFO was not included in the Source BSS to Target BSS 
transparent container received in the PS HANDOVER REQUEST message as specified in TS 48.018 [42], 
request the INTER RAT HANDOVER INFO from the target SGSN by setting the 'Request for Inter RAT 
Handover Info' to '1'. 

7. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message in step 6 and 7 
may arrive in any order in the Target SGSN. 

8. Then the Target SGSN knows that the UE has arrived to the target side and Target SGSN informs the Source 
MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. 
If ISR Activated is indicated, the source MME shall maintain the UE's contexts and activate ISR, which is only 
possible when the S-GW is not changed. The Source MME will also acknowledge that information. A timer in 
source MME is started to supervise when resources in Source eNodeB and Source Serving GW (for Serving GW 
relocation) shall be released. 
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Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the 
target SGSN allocated S-GW resources for indirect forwarding. 

9. The Target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the Target SGSN is now responsible for all the EPS Bearer 
Context(s) the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel 
Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and 
TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection. If the 
PDN GW requested UE's location and/or User CSG information (determined from the UE context), the SGSN 
also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time 
Zone has changed, the SGSN includes the UE Time Zone IE in this message. If Serving GW is not relocated but 
the Serving Network has changed or if the SGSN has not received any old Serving Network information from 
the old MME, the SGSN includes the new Serving Network IE in this message. In network sharing scenarios 
Serving Network denotes the serving core network. If indicated, ISR Activated indicates that ISR is activated, 
which is only possible when the S-GW was not changed. When the Modify Bearer Request does not indicate ISR 
Activated and S-GW is not changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to 
the other CN node that has bearer resources on the S-GW reserved. 

The SGSN releases the non-accepted EPS Bearer contexts by triggering the EPS Bearer context deactivation 
procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 
packet and does not send a Downlink Data Notification to the SGSN. 

10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the 
change of, for example, for Serving GW relocation or the RAT type, that e.g. can be used for charging, by 
sending the message Modify Bearer Request per PDN connection. The S-GW also includes User Location 
Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 9. Serving 
Network should be included if it is received in step 9 or in step 4 in clause 5.5.2.3.2. For Serving GW relocation, 
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge 
the request with the message Modify Bearer Response. In the case of Serving GW relocation, the PDN GW 
updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the 
Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. 

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 

1 1 . The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the Target SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options). At this 
stage the user plane path is established for all EPS Bearer contexts between the UE, Target BSS, Target SGSN, 
Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW. 

If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old 
path immediately after switching the path. 

12. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in 
the HO from E-UTRAN Command message, then on receipt of the PS Handover Complete the Target SGSN 
initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the Target 
SGSN wants to use the default XID parameters, it shall send an empty XID Command. If the Target SGSN 
indicated 'Reset to the old XID parameters' in the NAS container, no further XID negotiation is required for LLC 
SAPIs used in LLC ADM only. 

12a. The Target SGSN (re-)establishes LLC ABM for the EPS Bearer contexts which use acknowledged 
information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID 
negotiation. 

These steps (12 and 12a) are the same as specified in clause 5.3.2.2 in TS 43.129 [8]. 

13. After the UE has finished the reconfiguration procedure the UE shall initiate the Routing Area Update procedure. 

NOTE 1 : The RAU procedure is performed regardless if the UE has this routing area registered or not, as specified 
by TS 43.129 [8]. This is needed e.g. to update the START-PS value stored in the 2G-SGSN. The 
START_PS is delivered to SGSN in INTER RAT HANDOVER INFO parameter of RAU Complete 
message when requested by SGSN in RAU Accepted. 
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The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure, 
specifically it excludes the context transfer procedures between source MME and target SGSN. 

13a. Upon reception of the PS Handover Complete message with the 'Request for Inter RAT Handover Info' set to 
'1', the SGSN should send then PS Handover Complete Acknowledge (TLLI, INTER RAT HANDOVER INFO) 
to the target BSS. 

NOTE 2: An SGSN that does not recognize the "Request for Inter RAT Handover Info" in the PS Handover 

Complete message will not send the PS Handover Complete Acknowledge message back to the BSS. 

The target BSS receiving the PS Handover Complete Acknowledge message shall set the 'Reliable INTER RAT 
HANDOVER' to '1' in the PS Handover Required message in any subsequent PS handover to GERAN A/Gb 
mode. The target BSS failing to receive the PS Handover Complete Acknowledge message shall set the 'Reliable 
INTER RAT HANDOVER' to '0' in the PS Handover Required message in any subsequent PS handover to 
GERAN A/Gb mode. The Target BSS shall, upon receipt of the INTER RAT HANDOVER INFO in the PS 
Handover Complete Acknowledge message, overwrite its current INTER RAT HANDOVER INFO with this 
new one. 

14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source 
eNodeB. The Source eNodeB releases its resources related to the UE. 

When the timer started in step 8 expires and if the source MME received the Serving GW change indication in 
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session 
Request (Cause, Operation Indication) messages to the Source Serving GW. The operation Indication flag is not 
set, that indicates to the Source Serving GW that the Serving GW changes and the Source Serving GW shall not 
initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session 
Response (Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source 
S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete 
Bearer Request message(s) to that CN node. 

15. If indirect forwarding was used then the expiry of the timer at source MME started at step 8 triggers the source 
MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary 
resources used for indirect forwarding. 

16. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN 
started at step 8 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to 
the target S-GW to release temporary resources used for indirect forwarding. 

5.5.2.3.4 E-UTRAN to GERAN A/Gb mode Inter RAT handover reject 

The Target BSS may reject the use of the Handover procedure if none of the requested PFCs in the PS Handover 
Request message could be established. In this case no UE context is established in the target SGSN/BSS and no 
resources are allocated. The UE remains in the Source eNodeB/MME. 
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Figure 5.5.2.3.4-1 : E-UTRAN to GERAN A/Gb Inter RAT HO reject 

1. Steps 1 to 5 in the flow are identical to the ones in clause 5.5.2.3.2. 

6. If the Target BSS fails to allocate any resources for any of the requested PFCs it sends a PS Handover Request 
Nack (Cause) message to the Target SGSN. When the Target SGSN receives the PS Handover Request Nack 
message from Target BSS the Target SGSN clears any reserved resources for this UE. 

7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target SGSN 
deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving 
GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 

8. The Target SGSN sends the Forward Relocation Response (Cause) message to the Source MME. 

9. When the Source MME receives the Forward Relocation Response message it send a Handover Preparation 
Failure (Cause) message to the Source eNodeB. 



5.5.2.4 



GERAN A/Gb mode to E-UTRAN Inter RAT handover 



5.5.2.4.1 General 

The procedure is based on Packet-switched handover for GERAN A/Gb mode, defined in TS 43.129 [8]. 
Pre-conditions: 

- The UE is in READY state (GERAN A/Gb mode); 

The UE has at least one PDP/EPS Bearer Context established; 

The BSS must support PFM, Packet Flow Management, procedures. 
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Figure 5.5.2.4.2-1 : GERAN A/Gb mode to E-UTRAN inter RAT HO, preparation phase 

1. The source access system, Source BSS, decides to initiate an Inter-RAT Handover to the E-UTRAN. At this 
point both upHnk and downlink user data is transmitted via the following: Bearers between UE and Source BSS, 
BSSGP PFC tunnel(s) between source BSS and source SGSN, GTP tunnel(s) between Source SGSN, Serving 
GW and PDN GW. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this specification. 

2. The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target eNodeB 
Identifier, Source BSS to Target RNC Transparent Container and active PFCs list) to Source SGSN to request 
the CN to establish resources in the Target eNodeB, Target MME and the Serving GW. 

3. The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS 
Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending 
message Forward Relocation Request (IMSI, Target Identification, MM Context, PDN Connections, SGSN 
Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane. Source to Target Transparent 
Container, RAN Cause, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, MS Info Change 
Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR 
Supported, Serving Network) to the target MME. When ISR is activated the message should be sent to the MME 
that maintains ISR for the UE when this MME is serving the target identified by the Target Identification. If 
indicated, the information ISR Supported indicates that the source SGSN and associated Serving GW are capable 
to activate ISR for the UE. This message includes all PDN Connections active in the source system and for each 
PDN Connection includes the associated APN, the address and the uplink tunnel endpoint parameters of the 
Serving GW for control plane, and a list of EPS Bearer Contexts established in the source system. The EPS 
Bearer Contexts indicate the PFIs and the XID parameters related to those EPS Bearer Contexts, and the uplink 
Tunnel endpoint parameters of the Serving GW. The old Serving Network is sent to target MME to support the 
target MME to resolve if Serving Network is changed. In network sharing scenarios Serving Network denotes 
the serving core network. 

The RAN Cause includes the value from the Cause IE received from the source BSS. Source to Target 
Transparent Container includes the value from the Source BSS to Target RNC Transparent Container received 
from the source BSS. 

Prioritization of EPS Bearer Contexts is performed by the target core network node. 
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The MME establishes the EPS bearer(s) in the prioritized order. The MME deactivates, as provided in step 8 of 
the execution phase, the EPS bearers which cannot be established. 

The MM context contains security related information, e.g. supported ciphering algorithms as described in 
TS 29.274 [43]. HandUng of security keys is described in TS 33.401 [41]. 

For the EPS Bearer Context with traffic class equals 'Background', the source SGSN shall indicate via the 
Activity Status Indicator IE that radio bearers shall be established on the target side. 

The target MME shall determine the Maximum APN restriction based on the APN Restriction of each bearer 
context received in the Forward Relocation Request, and shall subsequently store the new Maximum APN 
restriction value. 

4. The target MME determines if the Serving GW is to be relocated, e.g. due to PLMN change. If the Serving GW 
is to be relocated, the target MME selects the target Serving GW as described under clause 4.3.8.2 on "Serving 
GW selection function". The target MME sends a Create Session Request message (IMSI, MME Tunnel 
Endpoint Identifier for Control Plane, MME Address for Control plane, PDN GW address(es) for user plane, 
PDN GW UL TEID(s) for user plane, PDN GW address for control plane, and PDN GW TEID(s) for control 
plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The 
Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. 

4a. The target Serving GW allocates its local resources and returns them in a Create Session Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target MME. 

5. The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover 
Request (UE Identifier, SI AP Cause, Integrity protection information (i.e. IK and allowed Integrity Protection 
algorithms). Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to be setup list. 
Source to Target Transparent Container, Handover Restriction List). The Target MME ignores any Activity 
Status Indicator within an EPS Bearer Context and requests the eNodeB to allocate resources for all EPS Bearer 
Contexts received from the source side. The SlAP Cause includes the value from the RAN Cause IE received 
from the source SGSN. The target eNodeB shall ignore it if the number of radio bearers in the Source to Target 
Transparent container does not comply with the number of bearers requested by the MME and allocate bearers as 
requested by the MME. Handover Restriction List is sent if it is available in the Target MME; it is described in 
clause 4.3.5.7. 

For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as 
ID, bearer parameters. Transport Layer Address, "Data forwarding not possible" indication, and S 1 Transport 
Association. The Transport Layer Address is the Serving GW Address for user data, and the S 1 Transport 
Association corresponds to the uplink Tunnel Endpoint Identifier Data. "Data forwarding not possible" 
indication shall be included if the target MME decides the corresponding bearer will not be subject to data 
forwarding. 

The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the 
Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the UE. 
This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA 
(Authentication and Key Agreement) procedure. More details are described in TS 33.401 [41]. 

5a. The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME in 
the message Handover Request Acknowledge (Target to Source Transparent Container, SlAP Cause, EPS 
Bearers setup list, EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message 
the target eNodeB shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS 
bearers. 

6. If 'Indirect Forwarding' and relocation of Serving GW apply, the target MME sends a Create Indirect Data 
Forwarding Tunnel Request message (Target eNodeB Address(es) and TEID(s) for DL data forwarding) to the 
Serving GW. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) 
and DL TEID(s) for data forwarding) message to the target MME. 
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7. The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PFCs, MME Tunnel 
Endpoint Identifier for Control Plane, RAN Cause, MME Address for control plane. Target to Source 
Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving GW change indication) to the 
Source SGSN. Serving GW change indication indicates whether a new Serving GW has been selected. The RAN 
Cause includes the value from the SI AP Cause IE received from the target eNodeB. The Target to Source 
Transparent Container includes the value from the Target to Source Transparent Container received from the 
target eNodeB. 

If 'Direct Forwarding' applies or if 'Indirect Forwarding' but no relocation of Serving GW applies, then the lEs 
'Address(es) and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the 
eNodeB received in step 5a. If 'Indirect Forwarding' and relocation of Serving GW apply the lEs 'Address(es) 
and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the Serving GW 
received in step 6a. 

8. If 'Indirect Forwarding' applies, the source SGSN shall send the message Create Indirect Data Forwarding 
Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for 
indirect packet forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Indirect Data 
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the 
Serving GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW 
Address(es) and TEID(s) will not be included in the message. 
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Figure 5.5.2.4.3-1 : GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase 

NOTE: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 9a concern GTP 
based S5/S8. 

The source SGSN continues to receive downlink and uplink user plane PDUs. 

When source SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and 
duplication to the target eNodeB (for Direct Forwarding) or via the Serving GW (for Indirect Forwarding), and the 
target eNodeB may start blind transmission of downlink user data towards the UE over the allocated radio channels. 

1. The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO 

Required Acknowledge (TLLI, List of Set Up PFCs, Target RNC to Source BSS Transparent Container, Cause). 
This message includes all PFIs that could be established on the Target side. The Cause includes the value from 
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the RAN Cause IE received from the target MME. The Target RNC to Source BSS Transparent Container 
includes the value from the Target to Source Transparent Container received from the target MME. 

Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink data 
transfer for any EPS Bearer contexts. 

Before sending the PS Handover Command message to the UE the source BSS, may try to empty the downlink 
BSS buffer for any BSS PFCs. 

2. The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover 
Command. The access system specific message to UE includes a transparent container including radio aspect 
parameters that the Target eNodeB has set-up in the preparation phase. 

3. Void. 

4. The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB. 

5. When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete. 

The UE shall implicitly derive the EPS bearers for which an E-RAB was not established from the PS Handover 
Command and deactivate them locally without an explicit NAS message at this step. 

6. When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by 
sending the message Handover Notify (TAIh-ECGI). 

7. Then the Target MME knows that the UE has arrived to the target side and Target MME informs the Source 
SGSN by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. 
If indicated, ISR Activated indicates to the source SGSN that it shall maintain the UE's contexts and activate 
ISR, which is only possible when the S-GW is not changed. The Source SGSN shall also acknowledge that 
information. When the Forward Relocation Complete Notification message has been received and there is no 
longer any need for the SGSN to forward data, the SGSN stops data forwarding. A timer in source SGSN is 
started to supervise when resources in the Source Serving GW (for Serving GW relocation) shall be released. 

Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a timer if the 
target MME applies indirect forwarding. 

8. The Target MME will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the Target MME is now responsible for all the EPS bearers 
the UE have established. This is performed in the message Modify Bearer Request (Cause, MME Tunnel 
Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB Address(es) 
and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection. 
If the PDN GW requested UE's location and/or User CSG information (determined from the UE context), the 
MME also includes the User Location Information IE and/or User CSG Information IE in this message. If the 
UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If the Serving GW is not 
relocated but the Serving Network has changed or if the MME has not received any old Serving Network 
information from the old SGSN, the MME includes the new Serving Network IE in this message. If indicated, 
ISR Activated indicates that ISR is activated, which is only possible when the S-GW was not changed. When the 
Modify Bearer Request does not indicate ISR Activated and S-GW is not changed, the S-GW deletes any ISR 
resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S-GW 
reserved. 

The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in 

clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 

packet and does not send a Downlink Data Notification to the MME. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) informs the PDN GW(s) the 
change of, for example, for Serving GW relocation or the RAT type, that e.g. can be used for charging, by 
sending the message Modify Bearer Request per PDN connection. The S-GW also includes User Location 
Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 8. Serving 
Network should be included if it is received in step 8 or in step 4 in clause 5.5.2.4.2. For Serving GW relocation, 
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge 
the request with the message Modify Bearer Response (Charging Id, MSISDN, etc.) to the Serving GW. 

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 
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10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the Target MME via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW (for Serving GW relocation this will be the Target Serving GW) 
Address for Control Plane, Protocol Configuration Options). At this stage the user plane path is established for 
all bearers between the UE, Target eNodeB, Serving GW (for Serving GW relocation this will be the Target 
Serving GW) and PDN GW. 

If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old 
path immediately after switching the path in order to assist the reordering function in the target eNodeB. 

11. When the timer at the source SGSN started in step 7 expires the Source SGSN will clean-up all its resources 
towards Source BSS by performing the BSS Packet Flow Delete procedure. 

12. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for 
tracking area update" applies. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. 

13. When the timer at the source SGSN started in step 7 expires and if the source SGSN received the Serving GW 
change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending 
Delete Session Request (Cause, Operation Indication) messages to the Source Serving GW. The operation 
Indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a 
delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response 
(Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source S-GW that 
the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request 
message(s) to that CN node. 

14. If indirect forwarding was used then the expiry of the timer at source SGSN started at step 7 triggers the source 
SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary 
resources used for indirect forwarding. 

15. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target MME 
started at step 6 triggers the target MME to send a Delete Indirect Data Forwarding Tunnel Request message to 
the target S-GW to release temporary resources used for indirect forwarding. 

5.5.2.4.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover reject 

The Target eNodeB may reject the use of the Handover procedure if none of the requested EPS bearers in the Handover 
Request message could be established. In this case no UE context is established in the target MME/eNodeB and no 
resources are allocated. The UE remains in the Source BSS/SGSN. 
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Figure 5.5.2.4.4-1 : GERAN A/Gb mode to E-UTRAN inter RAT HO reject 

1. Steps 1 to 5 in the flow are identical to the ones in clause 5.5.2.4.2. 

6. If the Target eNodeB fails to allocate any resources for any of the requested EPS Bearers it sends a Handover 
Failure (Cause) message to the Target MME. When the Target MME receives the Handover Failure message 
from Target eNodeB the Target MME clears any reserved resources for this UE. 

7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target MME 
deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving 
GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 

8. The Target MME sends the Forward Relocation Response (Cause) message to the Source SGSN. 

9. When the Source SGSN receives the Forward Relocation Response message it send a PS Handover Required 
Negative Acknowledge (Cause) message to the Source BSS. 



5.5.2.5 



Inter RAT handover Cancel 



5.5.2.5.1 



General 



Instead of completing the handover procedure, the source RAN node (eNodeB, RNC or BSS) may at any time during 
the handover procedure, up to the time when a handover command message is sent to the UE cancel the handover. The 
reason for cancelling may be e.g. due to a timer expiration or due to other events within the source RAN node and is 
initiated by sending a handover cancel PDU to the source EPC node (MME or SGSN). 

A handover cancel PDU shall also be sent by the source RAN node after a handover command message is sent to the 
UE for the case where the handover fails and the UE returns to the old cell or radio contact with the UE is lost. This is 
done in order to release the resources reserved for the Handover in the target system. 
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5.5.2.5.2 
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Figure 5.5.2.5.2-1 : Inter RAT handover Cancel 

1 . The source RAN decides to cancel the previously requested relocation of Handover resources. This may be due 
to not enough accepted bearers, UE returned to source cell or any other reason. 

2. The source RAN sends a Cancel message with a Cause to the source EPC node (SGSN or MME). If the source 
RAN is: 

a) BSS the message sent is PS Handover Cancel (Cause), 

b) RNC the message sent is Relocation Cancel (Cause), or 

c) eNodeB the message sent is Handover Cancel (Cause). 

3. The source EPC node terminates the relocation towards the target side by sending a Relocation Cancel Request 
(IMSI) message to the target EPC node. The Source EPC node also resumes operation on the resources in the 
source side. 

4. The target EPC node triggers the release of resources in the target RAN and also releases its own resources 
allocated for this handover. 

5. This step is only performed for Serving GW relocation. The Target EPC node deletes the EPS bearer resources 
by sending Delete Session Request (Cause) messages to the Target Serving GW. The Target Serving GW 
acknowledges with Delete Session Response (Cause) messages. 
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6. The target EPC node acknowledge the release of all resources on the target side by returning a Relocation Cancel 
Response (Cause) message to the source EPC node. 

7. The source EPC node returns a Cancel acknowledge message to the source RAN. If the source RAN is: 

a) BSS there will be no acknowledge message sent to the source BSS, 

b) RNC the message sent is Relocation Cancel Acknowledge (Cause), or 

c) eNodeB the message sent is Handover Cancel Acknowledge (Cause). 

8. If indirect forwarding tunnel is setup during handover preparation then cancellation of handover triggers the 
source MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release 
the temporary resources used for indirect forwarding. 

9. If indirect forwarding tunnel is setup during handover preparation and serving GW is relocated then cancellation 
of handover triggers the target MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message 
to the S-GW to release the temporary resources used for indirect forwarding. 



5.6 Network Assisted Cell Change 



Network Assisted Cell Change (NACC) is a means that enables better performance for packet data services upon inter- 
cell change for those networks that do not support PS Handover. It reduces the service interruption time for UEs in 
active mode upon cell change by providing in the source cell, prior to the cell change, system information of a target 
cell allowing packet access. 

Within the scope of this specification, NACC is applicable for inter-RAT cell changes from a source E-UTRAN cell 
towards a target GERAN cell. 

When the UE changes from a source E-UTRAN cell towards a target GERAN cell, the UE locally deactivates ISR by 
setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer context activated after the ISR was activated in 
the UE exists. 

5.6.1 Architecture Principles for E-UTRAN to GERAN NACC 

Introducing NACC from E-UTRAN to GERAN follows the principles of the Network Assisted Cell Change between 
UTRAN and GERAN as described in TS 25.413 [22] and TS 23.060 [7]. It specifies the RAN Information Management 
(RIM) procedures as specified in clause 5.15 and depicted in figure 5.6-1. 
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Figure 5.6-1 : E-UTRAN to GERAN NACC basic networic archiitecture 
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The support for the NACC from E-UTRAN to GERAN has the following impacts on E-UTRAN / GERAN architecture: 

- Affected nodes: BSC, eNodeB, MME, SGSN; 

- Affected network interfaces: Gb, lu, S3, Gn, SI; 
Affected radio interfaces: Um and Uu. 

5.6.2 Void 



5.7 Information storage 

This clause describes information storage structures required for the EPS when 3GPP access only is deployed. 
Information storage for the case where non 3GPP accesses are deployed is in TS 23.402 [2]. 
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5.7.1 



HSS 



IMSI is the prime key to the data stored in the HSS. The data held in the HSS is defined in Table 5.7.1-1 here below. 
The table below is applicable to E-UTRtVN in standalone operation only. 

Table 5.7.1-1: HSS data 



Field 


Description 


IMSI 


IMSI is the main reference key. 


MSISDN 


The basic MSISDN of the UE (Presence of MSISDN is optional). 


IMEI/IMEISV 


International Mobile Equipment Identity - Software Version Number 


MME Identity 


The Identity of the MME currently serving this MS. 


MME Capabilities 


Indicates the capabilities of the MME with respect to core functionality e.g. 
regional access restrictions. 


IVIS PS Purged from EPS 


Indicates that the EMM and ESM contexts of the UE are deleted from the MME. 


ODB parameters 


Indicates that the status of the operator determined barring 


Access Restriction 


Indicates the access restriction subscription information. 


EPS Subscribed Charging 
Characteristics 


The charging characteristics for the MS, e.g. normal, prepaid, flat-rate, and/or 
hot billing subscription. 


Trace Reference 


Identifies a record or a collection of records for a particular trace. 


Trace Type 


Indicates the type of trace, e.g. HSS trace, and/or MME/ Serving GW / PDN GW 
trace. 


OIVIC Identity 


Identifies the OMC that shall receive the trace record(s). 


Subscribed-UE-AMBR 


The Maximum Aggregated uplink and downlink MBRs to be shared across all 
Non-GBR bearers according to the subscription of the user. 


APN-OI Replacement 


Indicates the domain name to replace the APN 01 when constructing the PDN 
GW FODN upon which to perform a DNS resolution. This replacement applies 
for all the APNs in the subscriber's profile. See TS 23.003 [9] clause 9.1.2 for 
more information on the format of domain names that are allowed in this field. 


RFSP Index 


An index to specific RRM configuration in the E-UTRAN 


URRP-MME 


UE Reachability Request Parameter indicating that UE activity notification from 
MME has been requested by the HSS. 


CSG Subscription Data 


The CSG Subscription Data is a list of CSG IDs per PLMN and for each CSG ID 
optionally an associated expiration date which indicates the point in time when 
the subscription to the CSG ID expires; an absent expiration date indicates 
unlimited subscription. 

For a CSG ID that can be used to access specific PDNs via Local IP Access, the 
CSG ID entry includes the corresponding APN(s). 


VPLMNLIPA Allowed 


Specifies per PLMN whether the UE is allowed to use LIPA. 


Subscribed Periodic RAU/TAU 
Timer 


Indicates a subscribed Periodic RAU/TAU Timer value 


IVIPS CS priority 


Indicates that the UE is subscribed to the eMLPP or 1x RTT priority service in 
the CS domain. 


UE-SRVCC- Capability 


Indicates whether the UE is UTRAN/GERAN SRVCC capable or not. 


MPS EPS priority 


Indicates that the UE is subscribed to MPS in the EPS domain. 


Each subscription profile contains one or more PDN subscription contexts: 


Context Identifier 


Index of the PDN subscription context. 


PDN Address 


Indicates subscribed IP address{es). 


PDN Type 


Indicates the subscribed PDN Type (IPv4, IPv6, IPv4v6) 


APN-OI Replacement 


APN level APN-OI Replacement which has same role as UE level APN-OI 
Replacement but with higher priority than UE level APN-OI Replacement. This is 
an optional parameter. When available, it shall be used to construct the 
PDN GW FODN instead of UE level APN-OI Replacement. 


Access Point Name (APN) 


A label according to DNS naming conventions describing the access point to the 
packet data network (or a wildcard) (NOTE 6). 


SIPTO permissions 


Indicates whether the traffic associated with this APN is allowed or prohibited for 
SIPTO 


LIPA permissions 


Indicates whether the PDN can be accessed via Local IP Access. Possible 
values are: LIPA-prohibited, LIPA-only and LIPA-conditional. 


EPS subscribed QoS profile 


The bearer level QoS parameter values for that APN's default bearer (OCI and 
ARP) (see clause 4.7.3). 


Subscribed-APN-AMBR 


The maximum aggregated uplink and downlink MBRs to be shared across all 
Non-GBR bearers, which are established for this APN. 
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Field 


Description 


EPS PDN Subscribed Charging 
Characteristics 


The charging characteristics of this PDN Subscribed context for the MS, e.g. 
normal, prepaid, flat-rate, and/or hot billing subscription. The charging 
characteristics is associated with this APN. 


VPLMN Address Allowed 


Specifies whether for this APN the UE is allowed to use the PDN GW in the 
domain of the HPLMN only, or additionally the PDN GW in the domain of the 
VPLMN. 


PDN GW identity 


The identity of the PDN GW used for this APN. The PDN GW identity may be 
either an FQDN or an IP address. The PDN GW identity refers to a specific PDN 
GW. 


PDN GW Allocation Type 


Indicates whether the PDN GW is statically allocated or dynamically selected by 
other nodes. A statically allocated PDN GW is not changed during PDN GW 
selection. 


PLMN of PDN GW 


Identifies the PLMN in which the dynamically selected PDN GW is located. 


Homogenous Support of IMS Over 
PS Sessions for IVIME 


Indicates whether or not "IMS Voice over PS Sessions" is supported 
homogeneously in all TAs in the serving MME. 


List of APN - PDN GW ID relations (for PDN subscription context with wildcard APN): 


APN - P-GW relation #n 


The APN and the identity of the dynamically allocated PDN GW of a PDN 
connection that is authorised by the PDN subscription context with the wildcard 
APN. The PDN GW identity may be either an FQDN or an IP address. The 
PDN GW identity refers to a specific PDN GW. 



NOTE 1: IMEI and SVN are stored in HSS when the Automatic Device Detection feature is supported, see clause 
15.5 ofTS 23.060 [7]. 

NOTE 2: The 'EPS subscribed QoS profile' stored in HSS is complementary to the legacy 'GPRS subscribed QoS 
profile'. 

NOTE 3: Void. 

NOTE 4: How to indicate which of the PDN subscription contexts stored in the HSS is the default one for the UE is 
defined in stage 3. 

NOTE 5: To help with the selection of a co-located or topologically appropriate PDN GW and Serving GW, the 
PDN GW identity shall be in the form of an FQDN. 

NOTE 6: The "Access Point Name (APN)" field in the table above contains the APN-NI part of the APN. 

An expired CSG subscription should not be removed from the HSS subscription data before it is removed from the UE's 
Allowed CSG list or Operator CSG list. When a CSG subscription is cancelled it should be handled as an expired 
subscription in HSS subscription data to allow for removing it from UE's Allowed CSG list or Operator CSG list first. 

One (and only one) of the PDN subscription contexts stored in the HSS may contain a wild card APN (see 
TS 23.003 [9]) in the Access Point Name field. 

The PDN subscription context marked as the default one shall not contain a wild card APN. 

The PDN subscription context with a wildcard APN shall not contain a statically allocated PDN GW. 
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5.7.2 



MME 



The MME maintains MM context and EPS bearer context information for UEs in the ECM-IDLE, ECM-CONNECTED 
and EMM-DEREGISTERED states. Table 5.7.2-1 shows the context fields for one UE. 

Table 5.7.2-1 : MME MM and EPS bearer Contexts 



Field 



IMS! 



IMSI-unauthenticated-indicator 

MSISDN 

MM State 

GUTI 

ME Identity 

Tracking Area List 

TAI of last TAU 

E-UTRAN Cell Global Identity 

E-UTRAN Cell Identity Age 

GSG ID 

CSG membership 

Access mode 

Authentication Vector 



UE Radio Access Capability 
MS Classmark 2 

MS Classmark 3 

Supported Codecs 

UE Network Capability 

MS Network Capability 

UE Specific DRX Parameters 
Selected NAS Algorithm 
Selected AS Algorithm 
eKSI 

Kasme 

NAS Keys and COUNT 
Selected CN operator id 

Recovery 
Access Restriction 
ODB for PS parameters 

APN-OI Replacement 



MME IP address for S11 

MMETEIDforSII 

S-GW IP address for S11/S4 

S-GWTEIDforS11/S4 
SGSN IP address for S3 



Description 

IMSI (International Mobile Subscriber Identity) is the subscribers permanent 
identity. 

This is an IMSI indicator to show the IMSI is unauthenticated. 
The basic MSISDN of the UE. The presence is dictated by its storage In the HSS. 
Mobility management state ECM-IDLE, ECM-CONNECTED, EMM- 
DEREGISTERED. 
Globally Unique Temporary Identity. 

Mobile Equipment Identity - (e.g. IMEI/IMEISV) Software Version Number 
Current Tracking area list 

TAI of the TA in which the last Tracking Area Update was initiated. 
Last known E-UTRAN cell 

Time elapsed since the last E-UTRAN Cell Global Identity was acquired 
Last known CSG ID when the UE was active 
Last known CSG membership of the UE when the UE was active 
Access mode of last known ECGI when the UE was active 
Temporary authentication and key agreement data that enables an MME to 
engage in AKA with a particular user. An EPS Authentication Vector consists of 
four elements: 

a) network challenge RAND, 

b) an expected response XRES, 

c) Key Kasme, 

d) a network authentication token AUTN. 
UE radio access capabilities. 

GERAN/UTRAN CS domain core network classmark (used if the MS supports 

SRVCC to GERAN or UTRAN) 

GERAN CS domain radio network classmark (used if the MS supports SRVCC to 

GERAN) 

List of codecs supported in the CS domain (used if the MS supports SRVCC to 

GERAN or UTRAN) 

UE network capabilities including security algorithms and key derivation functions 

supported by the UE 

For a GERAN and/or UTRAN capable UE, this contains information needed by the 

SGSN. 

UE specific DRX parameters for A/Gb mode, lu mode and SI -mode 

Selected NAS security algorithm 

Selected AS security algorithms. 

Key Set Identifier for the main key Kasme- Also indicates whether the UE is using 

security keys derived from UTRAN or E-UTRAN security association. 

Main key for E-UTRAN key hierarchy based on CK, IK and Serving network 

identity 

KNASint, K_NASenc, and NAS COUNT parameter. 

Selected core network operator identity (to support network sharing as defined in 

TS 23.251 [24]). 

Indicates if the HSS is performing database recovery. 

The access restriction subscription information. 

Indicates that the status of the operator determined barring for packet oriented 

services. 

Indicates the domain name to replace the APN-OI when constructing the PDN GW 

FQDN upon which to perform a DNS resolution. This replacement applies for all 

the APNs in the subscriber's profile. See TS 23.003 [9] clause 9.1 .2 for more 

information on the format of domain names that are allowed in this field. 

MME IP address for the S1 1 interface (used by S-GW) 

MME Tunnel Endpoint Identifier for S1 1 interface. 

S-GW IP address for the S1 1 and S4 interfaces 

S-GW Tunnel Endpoint Identifier for the S1 1 and S4 interfaces. 

SGSN IP address for the S3 interface (used if ISR is activated for the GERAN and 

/or UTRAN capable UE) 
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Field 

SGSNTEIDforSS 

eNodeB Address in Use for S1- 

MME 

eNBUESIAPID 

MMEUES1APID 

Subscribed UE-AIVIBR 

UE-AIVIBR 

EPS Subscribed Charging 
Characteristics 
Subscribed RFSP Index 

RFSP Index in Use 
Trace reference 
Trace type 
Trigger id 
OIVIC identity 
URRP-IVIIVIE 

CSG Subscription Data 



LIRA Allowed 

Subscribed Periodic RAU/TAU 

Timer 

MPS CS priority 

MPS EPS priority 

For each active PDN connection: 

APN in Use 



APN Restriction 

APN Subscribed 
PDN Type 
IP Address(es) 



EPS PDN Charging 
Characteristics 
APN-OI Replacennent 



SIPTO permissions 

LIRA permissions 

VPLMN Address Allowed 

PDN GW Address In Use 

(control plane) 

PDN GW TEID for S5/S8 

(control plane) 

MS Info Change Reporting 

Action 



Description 

SGSN Tunnel Endpoint Identifier for S3 interface (used if ISR is activated for the 

E-UTRAN capable UE) 

The IP address of the eNodeB currently used for S1 -MME. 

Unique identity of the UE within eNodeB. 

Unique identity of the UE within MME. 

The Maximum Aggregated uplink and downlink MBR values to be shared across 

all Non-GBR bearers according to the subscription of the user. 

The currently used Maximum Aggregated uplink and downlink MBR values to be 

shared across all Non-GBR bearers. 

The charging characteristics for the MS e.g. normal, prepaid, flat rate and/or hot 

billing. 

An index to specific RRM configuration in the E-UTRAN that is received from the 

HSS. 

An index to specific RRM configuration in the E-UTRAN that is currently in use. 

Identifies a record or a collection of records for a particular trace. 

Indicates the type of trace 

Identifies the entity that initiated the trace 

Identifies the OMC that shall receive the trace record(s). 

URRP-MME indicating that the HSS has requested the MME to notify the HSS 

regarding UE reachability at the MME 

The CSG Subscription Data is a list of CSG IDs for the visiting PLMN and for each 

CSG ID optionally an associated expiration date which indicates the point in time 

when the subscription to the CSG ID expires; an absent expiration date indicates 

unlimited subscription. 

For a CSG ID that can be used to access specific PDNs via Local IP Access, the 

CSG ID entry includes the corresponding APN(s). 

Specifies whether the UE is allowed to use LIRA in this PLMN. 

Indicates a subscribed Periodic RAU/TAU Timer value. 

Indicates that the UE is subscribed to the eMLPP or 1x RTT priority service in the 

CS domain. 

Indicates that the UE is subscribed to MPS in the EPS domain. 

The APN currently used. This APN shall be composed of the APN Network 

Identifier and the default APN Operator Identifier, as specified in TS 23.003 [9], 

clause 9.1 .2. Any received value in the APN 01 Replacement field is not applied 

here. 

Denotes the restriction on the combination of types of APN for the APN associated 

with this EPS bearer Context. 

The subscribed APN received from the HSS. 

IPv4, IPv6 or IPv4v6 

IPv4 address and/or IPv6 prefix 

NOTE: The MME might not have information on the allocated IPv4 address. 
Alternatively, following mobility involving a pre-release 8 SGSN, this 
IPv4 address might not be the one allocated to the UE. 

The charging characteristics of this PDN connection, e.g. normal, prepaid, flat-rate 

and/or hot billing. 

APN level APN-OI Replacement which has same role as UE level APN-OI 

Replacement but with higher priority than UE level APN-OI Replacement. This is 

an optional parameter. When available, it shall be used to construct the PDN GW 

FODN instead of UE level APN-OI Replacement. 

Indicates whether the traffic associated with this APN is allowed or prohibited for 

SIPTO 

Indicates whether the PDN can be accessed via Local IP Access. Possible values 

are: LIPA-prohibited, LIPA-only and LIPA-conditional. 

Specifies whether the UE is allowed to use the APN in the domain of the HPLMN 

only, or additionally the APN in the domain of the VPLMN. 

The IP address of the PDN GW currently used for sending control plane signalling. 

PDN GW Tunnel Endpoint Identifier for the S5/S8 interface for the control plane. 
(For GTP-based S5/S8 only). 

Need to communicate change in User Location Information to the PDN GW with 
this EPS bearer Context. 
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Field 

CSG Information Reporting 
Action 



EPS subscribed QoS profile 
Subscribed APN-AMBR 

APN-AIVIBR 



PDN GW GRE Key for uplinl< 
traffic (user plane) 
Default bearer 
low access priority 



For each bearer within the PDN 
EPS Bearer ID 

Tl 

S-GW IP address for S1-U 

S-GWTEIDforS1u 

PDN GW TEID for S5/S8 (user 

plane) 



PDN GW IP address for S5/S8 
(user plane) 



EPS bearer QoS 
TFT 



Description 

Need to communicate change in User CSG Information to the PDN GW with this 

EPS bearer Context. 

This field denotes separately whether the MME/SGSN are requested to send 

changes in User CSG Information for (a) CSG cells, (b) hybrid cells in which the 

subscriber is a CSG member and (c) hybrid cells in which the subscriber is not a 

CSG member. 

The bearer level QoS parameter values for that APN's default bearer (QCI and 

ARP) (see clause 4.7.3). 

The Maximum Aggregated uplink and downlink MBR values to be shared across 

all Non-GBR bearers, which are established for this APN, according to the 

subscription of the user. 

The IVIaximum Aggregated uplink and downlink MBR values to be shared across 

all Non-GBR bearers, which are established for this APN, as decided by the 

PDN GW. 

PDN GW assigned GRE Key for the S5/S8 interface for the user plane for uplink 

traffic. (For PMIP-based S5/S8 only) 

Identifies the EPS Bearer Id of the default bearer within the given PDN connection. 

Indicates that the UE requested low access priority when the PDN connection was 

opened. 

NQTE: The low access priority indicator is only stored for the purpose to be 

included in charging records, 
connection: 

An EPS bearer identity uniquely identifies an EP S bearer for one UE accessing 

via E-UTRAN 

Transaction Identifier 

IP address of the S-GW for the Sl-u interfaces. 

Tunnel Endpoint Identifier of the S-GW for the Sl-u interface. 

P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the user plane. (Used 

for S-GW change only). 

NQTE: The PDN GW TEID is needed in MME context as S-GW relocation is 

triggered without interaction with the source S-GW, e.g. when a TAU 

occurs. The Target S-GW requires this Information Element, so it must 

be stored by the MME. 
P GW IP address for user plane for the S5/S8 interface for the user plane. (Used 
for S-GW change only). 
NQTE: The PDN GW IP address for user plane is needed in MME context as 

S-GW relocation is triggered without interaction with the source S-GW, 

e.g. when a TAU occurs. The Target S GW requires this Information 

Element, so it must be stored by the MME. 
QCI and ARP 

optionally: GBR and MBR for GBR bearer 
Traffic Flow Template. (For PMIP-based S5/S8 only) 



Table 5.7.2-2: MME Emergency Configuration Data 

The MME Emergency Configuration Data is used instead of UE subscription data received from the HSS, for all 
emergency bearer services that are established by an MME on UE request. 



Field 

Emergency Access Point Name 
(em APN) 
Emergency QoS profile 

Emergency APN-AMBR 



Emergency PDN GW identity 

Non-3GPP HQ Emergency PDN 
GW identity 



Description 

A label according to DNS naming conventions describing the access point used for 

Emergency PDN connection (wild card not allowed). 

The bearer level QoS parameter values for Emergency APN's default bearer (QCI 

and ARP). The ARP is an ARP value reserved for emergency bearers. 

The Maximum Aggregated uplink and downlink MBR values to be shared across 

all Non-GBR bearers, which are established for the Emergency APN, as decided 

by the PDN GW. 

The statically configured identity of the PDN GW used for emergency APN. The 

PDN GW identity may be either an FQDN or an IP address. 

The statically configured identity of the PDN GW used for emergency APN when a 

PLMN supports handover to non-3GPP access. The PDN GW identity may be 

either an FQDN or an IP address. (NOTE 1 ) 



NQTE-1 : The FQDN always resolves to one PDN GW. 



NOTE: QCI for Emergency APN's default bearer is set per operator configuration. 
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5.7.3 Serving GW 

The Serving GW maintains the following EPS bearer context information for UEs. Table 5.7.3-1 shows the context 
fields for one UE. 

For emergency attached UEs which are not authenticated, IMEI is stored in context. 
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Table 5.7.3-1 : S-GW EPS bearer context 



Field 



IMS! 



IMSI-unauthenticated- 
indicator 
ME Identity 
MSISDN 

Selected CN operator id 

MMETEIDforSII 

MME IP address for S11 

S-GW IE ID for S 11 /S4 

(control plane) 

S-GW IP address for S11/S4 

(control plane) 

SGSN IP address for S4 

(control plane) 

SGSN TEID for S4 (control 

plane) 

Trace reference 

Trace type 
Trigger id 
OIVIG identity 
Last known Cell Id 

Last known Cell Id age 



Description 

IMSI (International Mobile Subscriber Identity) is the subscriber 

permanent identity. 

This is an IMSI indicator to show the IMSI is unauthenticated. 

Mobile Equipment Identity (e.g. IMEI/IMEISV). 

The basic MSISDN of the UE. The presence is dictated by its 

storage in the HSS. 

Selected core network operator identity (to support network 

sharing as defined in TS 23.251 [24]). 

MME Tunnel Endpoint Identifier for the S1 1 interface 

MME IP address the S1 1 interface. 

S-GW Tunnel Endpoint Identifier for the S1 1 Interface and the 

S4 Interface (control plane). 

S-GW IP address for the S1 1 interface and the S4 Interface 

(control plane). 

SGSN IP address for the S4 interface (Used by the S-GW). 

SGSN Tunnel Endpoint Identifier for the S4 interface. 

Identifies a record or a collection of records for a particular 

trace. 

Indicates the type of trace 

Identifies the entity that initiated the trace 

Identifies the OMC that shall receive the trace record(s). 

This is the last location of the UE known by the network 

This is the age of the above UE location information 



For each PDN Connection: 

NOTE: The following entries are repeated for each PDN. 



APN in Use 

EPS PDN Charging 

Characteristics 

P-GW Address in Use 

(control plane) 

P-GW TEID for S5/S8 

(control plane) 

P-GW Address in Use (user 

plane) 

P-GW GRE Key for uplink 

traffic (user plane) 

S-GW IP address for S5/S8 

(control plane) 

S-GW TEID for S5/S8 

(control plane) 

S-GW Address in Use (user 

plane) 

S-GW GRE Key for downlink 

traffic (user plane) 

Default Bearer 



The APN currently used, as received from the MME or S4 

SGSN. 

The charging characteristics of this PDN connection, e.g. 

normal, prepaid, flat-rate and/or hot billing. 

The IP address of the P-GW currently used for sending control 

plane signalling. 

P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the 

control plane. (For GTP-based S5/S8 only). 

The IP address of the P-GW currently used for sending user 

plane traffic. (For PMIP-based S5/S8 only) 

PDN GW assigned GRE Key for the S5/S8 interface for the 

user plane for uplink traffic. (For PMIP-based S5/S8 only) 

S-GW IP address for the S5/S8 for the control plane signalling. 



S-GW Tunnel Endpoint Identifier for the S5/S8 control plane 

interface. (For GTP-based S5/S8 only). 

The IP address of the S-GW currently used for sending user 

plane traffic. (For PMIP-based S5/S8 only) 

Serving GW assigned GRE Key for the S5/S8 interface for the 

user plane for downlink traffic. (For PMIP-based S5/S8 only) 

Identifies the default bearer within the PDN connection by its 

EPS Bearer Id. (For PMIP based S5/S8.) 

For each EPS Bearer within the PDN Connection: 

NOTE:The following entries defining the EPS Bearer specific parameters are included within the 

the PDN Connection. 

EPS Bearer Id An EPS bearer identity uniquely identifies an EPS bearer for 

one UE accessing via E-UTRAN 
Traffic Flow Template 

The IP address of the P-GW currently used for sending user 
plane traffic. (For GTP-based S5/S8 only). 
P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the 
user plane. (For GTP-based S5/S8 only). 
S-GW IP address for user plane data received from PDN GW. 
(For GTP-based S5/S8 only). 



TFT 

P-GW Address in Use (user 

plane) 

P-GW TEID for S5/S8 (user 

plane) 

S-GW IP address for S5/S8 

(user plane) 



E-UTRAN 


UTRAN/ 




GERAN 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 




X 


X 


X 


X 




X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


(NOTE 1) 


(N0TE1) 


X 


X 


(NOTE 1) 


(N0TE1) 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


set of parameters defining 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 
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Field 


Description 


E-UTRAN 


UTRAN/ 
GERAN 


S-GW TEID for S5/S8 (user 


S-GW Tunnel Endpoint Identifier for the S5/S8 interface for the 


X 


X 


plane) 


user plane. (For GTP-based S5/S8 only). 






S-GW IP address for S1-U, 


S-GW IP address for the Sl-u interface (Used by the eNodeB), 


X 


X 


SI 2 and S4 (user plane) 


for the SI 2 interface (used by the RNC) and for the S4 
interface (used by the SGSN). 






S-GW TEID for S1-U, SI 2 


S-GW Tunnel Endpoint Identifier for the S1 -u interface, for the 


X 


X 


and S4 (user plane) 


SI 2 interface (used by the RNC) and for the S4 interface (used 
by the SGSN). 






eNodeB IP address for Sl-u 


eNodeB IP address for the Sl-u interface (Used by the S-GW). 


X 




eNodeBTEIDforS1-u 


eNodeB Tunnel Endpoint Identifier for the Sl-u interface. 


X 




RNC IP address for S1 2 


RNC IP address for the S12 interface (Used by the S-GW). 




X 


RNC TEID for S12 


RNC Tunnel Endpoint Identifier for the SI 2 interface. 




X 


SGSN IP address for S4 


SGSN IP address for the S4 interface (Used by the S-GW). 




X 


(user plane) 








SGSN TEID for S4 (user 

plane) 

EPS Bearer QoS 


SGSN Tunnel Endpoint Identifier for the S4 interface. 




X 


ARP, GBR, MBR, QCI. 


X 


X 


Charging Id 


Charging identifier, identifies charging records generated by 
S-GW and PDN GW. 


X 


X 


NOTE 1 : When UE location information is made available from both E-UTRAN and UTRAN/GERAN, the Serving GW | 


stores the "Last Known Cell Id" and the "Last Known Cell Id Age" with the least age. 







5.7.4 PDN GW 

The PDN GW maintains the following EPS bearer context information for UEs. Table 5.7.4-1 shows the context fields 
for one UE. 

For emergency attached UEs which are not authenticated, IMEI is stored in context. 
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Table 5.7.4-1 : P-GW context 



Field 



IMS! 



IMSI-unauthenticated- 
indicator 
ME Identity 
MSISDN 

Selected CN operator id 

RAT type 
Trace reference 

Trace type 

Trigger id 

OIVIC identity 

For each APN in use: 

NOTE: The following entries 

APN in use 

APN-AMBR 



For each PDN Connection withi 

NOTE: The following entries 

IP Address{es) 

PDN type 

S-GW Address in Use 

(control plane) 

S-GW TEID for S5/S8 

(control plane) 

S-GW Address in Use (user 

plane) 

S-GW GRE Key for downlink 

traffic (user plane) 

P-GW IP address for S5/S8 

(control plane) 

P-GW TEID for S5/S8 

(control plane) 

P-GW Address in Use (user 

plane) 

P-GW GRE Key for uplink 

traffic (user plane) 

MS Info Change Reporting 

support indication 

MS Info Change Reporting 
Action 

CSG Information Reporting 
Action 



BCM 

Default Bearer 



EPS PDN Charging 
Characteristics 



Description 

IMSI (International Mobile Subscriber Identity) is the 

subscriber permanent identity. 

This is an IMSI indicator to show the IMSI is unauthenticated. 

Mobile Equipment Identity (e.g. IMEI/IMEISV). 

The basic MSISDN of the UE. The presence is dictated by its 

storage in the HSS. 

Selected core network operator identity (to support network 

sharing as defined in TS 23.251 [24]). 

Current RAT 

Identifies a record or a collection of records for a particular 

trace. 

Indicates the type of trace 

Identifies the entity that initiated the trace 

Identifies the OMC that shall receive the trace record(s). 

are repeated for each APN. 

The APN currently used, as received from the S-GW. 

The maximum aggregated uplink and downlink MBR values 

to be shared across all Non-GBR bearers, which are 

established for this APN. 

n the APN: 

are repeated for each PDN connection within the APN. 

IPv4 address and/or IPv6 prefix 

IPv4, IPv6, or IPv4v6 

The IP address of the S-GW currently used for sending 

control plane signalling. 

S-GW Tunnel Endpoint Identifier for the S5/S8 interface for 

the control plane. (For GTP-based S5/S8 only). 

The IP address of the S-GW currently used for sending user 

plane traffic. (For PMIP-based S5/S8 only). 

Serving GW assigned GRE Key for the S5/S8 interface for 

the user plane for downlink traffic. (For PMIP-based S5/S8 

only). 

P-GW IP address for the S5/S8 for the control plane 

signalling. 

P-GW Tunnel Endpoint Identifier for the S5/S8 control plane 

interface. (For GTP-based S5/S8 only). 

The IP address of the P-GW currently used for sending user 

plane traffic. (For PMIP-based S5/S8 only). 

PDN GW assigned GRE Key for the S5/S8 interface for the 

user plane for uplink traffic. (For PMIP-based S5/S8 only). 

The MME and/or SGSN serving the UE support(s) 

procedures for reporting User Location Information and/or 

User CSG Information changes. 

Denotes whether the MME and/or the SGSN is/are 

requested to send changes in User Location Information 

change for this bearer. 

Denotes whether the MME and/or the SGSN is/are 

requested to send changes in User CSG Information change 

for this bearer. 

This field denotes separately whether the MME/SGSN are 

requested to send changes in User CSG Information for (a) 

CSG cells, (b) hybrid cells in which the subscriber is a CSG 

member, and (c) hybrid cells in which the subscriber is not a 

CSG member, or any combination of the above. 

The negotiated Bearer Control Mode for GERAN/UTRAN. 

Identifies the default bearer within the PDN connection by its 

EPS Bearer Id. The default bearer is the one which is 

established first within the PDN connection. (For GTP based 

S5/S8 or for PMIP based S5/S8 if multiple PDN connections 

to the same APN are supported). 

The charging characteristics of this PDN connection e.g. 

normal, prepaid, flat-rate and/or hot billing. 



E-UTRAN 


UTRAN/ 




GERAN 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 



X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 



X 

X 
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Field 


Description 


E-UTRAN 


UTRAN/ 
GERAN 


For each EPS Bearer within 


the PDN Connection: 






NOTE 1 : The following entries defining the EPS Bearer specific parameters are included withir 


the set of parameters | 


defining the PDN Connection. 






NOTE 2: The following entries are stored only for GTP-based S5/S8. 






EPS Bearer Id 


An EPS bearer identity uniquely identifies an EPS bearer for 
one UE accessing via E-UTRAN 


X 


X 


TFT 


Traffic Flow Template 


X 


X 


S-GW Address in Use (user 


The IP address of the S-GW currently used for sending user 


X 


X 


plane) 


plane traffic. 






S-GW TEID for S5/S8 (user 


S-GW Tunnel Endpoint Identifier for the S5/S8 interface for 


X 


X 


plane) 


the user plane. 






P-GW IP address for S5/S8 


P-GW IP address for user plane data received from PDN 


X 


X 


(user plane) 


GW. 






P-GW TEID for S5/S8 (user 


P-GW Tunnel Endpoint Identifier for the GTP Based S5/S8 


X 


X 


plane) 


interface for user plane. 






EPS Bearer QoS 


ARP, GBR, MBR, OCI. 


X 


X 


Charging Id 


Charging identifier, identifies charging records generated by 
S-GW and PDN GW. 


X 


X 



5.7.5 UE 

The UE maintains the following context information. Table 5.7.5-1 shows the context fields. A GERAN or UTRAN 
capable UE maintains in addition the context information as described in a similar UE context table in TS 23.060 [7]. 
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Table 5.7.5-1 : UE context 



Field Description 

IMSI IMSI (International Mobile Subscriber Identity) is the subscribers permanent identity. 

EMM State Mobility management state EMM-REGISTERED, EMM-DEREGISTERED. 

GUTI Globally Unique Temporary Identity. 

ME Identity Mobile Equipment Identity - (e.g. IMEI/IMEISV) Software Version Number. 

Tracking Area List Current Tracking area list. 

last visited TAI A TAI which is contained in the TA list the UE registered to the network and which 

identifies the tracking area last visited by the UE. 
Selected NAS Algorithm Selected NAS security algorithm. 

Selected AS Algorithm Selected AS security algorithms. 

eKSI Key Set Identifier for the main key Kasme. Also indicates whether the UE is using 

security keys derived from UTRAN or E-UTRAN security association 
Kasme '^^''^ '^®y ^'-"' E-UTRAN key hierarchy based on CK, IK and Serving network identity. 

NAS Keys and COUNT KNASint, KNASenc, and NAS COUNT parameter. 

Temporary Identity used in This parameter is used internally by the UE to memorise which temporary ID it has 
Next update (TIN) to indicate in the Attach Request and RAU/TAU Request as specified in clause 

4.3.5.6. 
UE Specific DRX Preferred E-UTRAN DRX cycle length 

Parameters 
Allowed CSG list The Allowed CSG list, which is under both user and operator control, indicates the 

list of CSG IDs and the associated PLMN where the UE is a member. 
Operator CSG list The Operator CSG list, which is under exclusive Operator control, indicates the list 

of CSG IDs and the associated PLMN where the UE is a member. 
For each active PDN connection: 
APN in Use The APN currently used. This APN shall be composed of the APN Network Identifier 

and the default APN Operator Identifier, as specified in TS 23.003 [9], clause 9.1.2. 
APN-AMBR The maximum aggregated uplink and downlink MBR to be shared across all Non- 

GBR bearers, which are established for this APN. 
Assigned PDN Type The PDN Type assigned by the network (IPv4, IPv6, or IPv4v6). 

IP Address(es) IPv4 address and/or IPv6 prefix 

Default Bearer Identifies the default bearer within the PDN connection by its EPS Bearer Id. The 

default bearer is the one which is established first within the PDN connection. 
For each EPS Bearer within the PDN connection 
EPS Bearer ID An EPS bearer identity uniquely identifies an EPS bearer for one UE accessing via 

E-UTRAN. 
Tl Transaction Identifier 
EPS bearer OoS GBR and MBR for GBR bearer. 
TFT Traffic Flow Template. 



5.7.6 Handling of Wild Card APN 



When the wild card APN is present in the subscription context, the UE is authorized to connect to APNs which are not 
present in the subscription context. 

When a request is received for registering a PDN GW ID and there is no PDN subscription context with this APN, the 
nodes (HSS/MME/ S4 SGSN) shall store the PDN GW ID - APN relation for the UE. 

When a request is received for deregistering of PDN GW ID and there is no PDN subscription context with this APN, 
the nodes (HSS/MME/S4 SGSN) shall delete the PDN GW ID - APN relation from the list of APN - PDN GW ID 
relations. 

5.7A Charging 

Accounting functionality is provided by the Serving GW and the PDN GW. 

The Serving GW shall be able to collect and report for each UE accounting information, i.e. the amount of data 
transmitted in uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN connection. For 
GTP-based S5/S8 the accounting information is collected and reported per bearer. 

The Serving GW shall not collect UE accounting information for packets that are being processed for the sole purpose 
of indirect forwarding. 
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The Serving GW for inter-operator charging, and the PDN GW shall be able to interface the OFCS according to 
charging principles and through reference points specified in TS 32.240 [51]. 

The PDN GW shall be able to provide charging functionality for each UE according to TS 23.203 [6]. 

A PDN GW without a Gx interface shall be able to support flow based online and offline charging based on local 
configuration and interaction with the Online and Offline Charging Systems. 

The PDN GW shall be able to collect and report, for each UE, accounting information, i.e. the amount of data 
transmitted in uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN connection. For 
GTP-based S5/S8 the accounting information is collected and reported per bearer. 

The Charging identifier(s) generated by the PDN GW per bearer for GTP-based S5/S8 and per PDN connection for 
PMIP-based S5/S8 and the PDN GW address for control signalling enables the correlation of the reporting from a 
Serving GW and a PDN GW. 

The PDN GW receives Charging Characteristics from the Serving GW through GTP-S5/S8, or through PMIP for PMIP- 
based S5/S8. The handling of the Charging Characteristics in the P-GW is defined in TS 32.251 [44]. 

To enable CSG charging function for a subscriber consuming network services via a CSG cell or a hybrid cell. User 
CSG Information is transferred to the PDN GW as indicated by CSG Information Reporting Action. User CSG 
Information includes CSG ID, access mode and CSG membership indication. CSG membership indication of whether 
the UE is a member of the CSG is included if the access mode is hybrid. 

The valid CSG information shall be available in the serving GW and PDN GW in connected mode. 

The PCRF shall, if deployed, provide User CSG Information reporting rules to the PDN GW at Attach and PDN 
Connectivity Request. PDN GW sets the CSG Information Reporting Action IE according to the User CSG Information 
reporting rules and sends it to Serving GW and MME. 



5.8 



MBMS 



MBMS is a point- to -multipoint service in which data is transmitted from a single source entity to multiple recipients. 
Transmitting the same data to multiple recipients allows network resources to be shared. 

Support of MBMS for EPS is defined in TS 23.246 [13]. 



5.9 



Interactions with other services 



5.9.1 Location Reporting Procedure 

This procedure is used by an MME to request the eNodeB to report where the UE is currently located when the target 
UE is in ECM-CONNECTED state. The need for the eNodeB to continue reporting ceases when the UE transitions to 
ECM-IDLE. This procedure may be used for services that require accurate cell identification (e.g. for emergency calls, 
lawful intercept, charging). 



eNodeB 



MME 



1 . Location reporting control 



2. Location Report 



3. Cancel location reporting 



Figure 5.9.1-1: Location Reporting Procedure 
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1) The MME sends a Location Reporting Control message to the eNodeB. The Location Reporting Control 
message shall identify the UE for which reports are requested, the requested location information and may 
contain information such as reporting type. Requested location information is TAI+EGCI. Reporting type 
indicates whether the message is intended to trigger a single stand-alone report about the current Cell ID serving 
the UE or start the eNodeB to report whenever the UE changes cell. 

2) The eNodeB sends a Location Report message informing the MME about the location of the UE which shall 
include the requested location information. 

3) The MME can send a Cancel Location Reporting message to inform the eNodeB that it should terminate location 
reporting for a given UE. This message is needed only when the reporting was requested for a reporting period. 

NOTE: Location reporting is transferred during X2 handover, although new control signalling is not transferred 
during an active handover. 

5.9.2 Location Change Reporting Procedure 

The PGW may request for each PDN connection independently by using the "MS Info Change Reporting Action" 
parameter whether the MME shall report changes of ECGI/TAI and/or by using "CSG Information Reporting Action" 
parameter whether the MME shall report changes of user CSG information to the PGW. The PGW may also request the 
MME to stop reporting ECGI/TAI and/or user CSG information changes. The MME shall obey the last explicit 
instruction received from the PGW or source MME/S4-SGSN. 

If ECGI/TAI and/or user CSG information are permitted to be sent to the PGW operator according to MME operator's 
policy, the MME shall include an indication for the support of reporting changes in ECGI/TAI and/or user CSG 
information when signalling to the PGW during both mobility management and session management procedures. If the 
level of support changes during a mobility management procedure then the MME shall indicate the current level of 
support to the S-GW and shall in addition provide ECGI/TAI even if the PGW has not requested this information. This 
could for example happen during MME change when the level of support indicated by the old MME is not the same as 
in the new MME. 

NOTE 1: The inclusion of ECGI/TAI will trigger a Modify Bearer Request message from S-GW to the PGW and 
therefore this will make sure that the new level of support reaches the PGW. 

The PGW shall not request the MME to report ECGI/TAI and/or user CSG information changes if it has not received 
the indication for support from the MME. 

The following procedure shall be used for location change reports to the PGW where the report is not combined with 
other mobility management or session management signalling. The procedure shall only apply when the MME has been 
explicitly requested to report the ECGI and/or user CSG information changes. 

NOTE 2: Due to the increased signalling load, it is recommended that such reporting is only applied for a limited 
number of subscribers. 

Figure 5.9.2-1 represents the ECGI change triggering a report of change in ECGI, and/or the User CSG information 
change triggering a report of change in user CSG information. 
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eNodeB mmE I SGW 1 PGW 
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Figure 5.9.2-1 : Notification of the ECGI and/or user CSG information changes 
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la. If the ECGI of the UE changes, the MME receives the ECGI information Update from the eNodeB. 

lb. The MME detects that the user CSG information has changed by comparing with the MME stored user CSG 
information. 

NOTE 3: Step la and step lb are independent. It is also possible that these two changes are triggered at same time. 

2. If the MME has been requested to report the ECGI and/or user CSG information changes to the PGW for the UE, 
the MME shall send the Change Notification message to the SGW indicating the new ECGI and/or user CSG 
information. The MME stores the notified user CSG information. 

3. The SGW forwards the Change Notification message to the PGW. If dynamic FCC is deployed, and ECGI 
changes need to be conveyed to the PCRF, then the PGW shall send this information to the PCRF as defined in 
TS 23.203 [6]. 

4. The PGW sends the Change Notification Ack to the SGW. 

5. The SGW forwards the Change Notification Ack to the MME. 

5.10 Multiple-PDN support 

5.10.1 General 

The EPS shall support simultaneous exchange of IP traffic to multiple PDNs through the use of separate PDN GWs or 
single PDN GW. The usage of multiple PDNs is controlled by network policies and defined in the user subscription. 

The EPS shall support UE-initiated connectivity establishment in order to allow multiple PDN connections to one or 
more PDNs. It shall be possible for a UE to initiate disconnection from any PDN. 

All simultaneous active PDN connections of a UE that are associated with the same APN shall be provided by the same 
P-GW. 

UE support for multiple PDN connections is optional. 

5.10.2 UE requested PDN connectivity 

The UE requested PDN connectivity procedure for an E-UTRAN is depicted in figure 5.10.2-1. The procedure allows 
the UE to request for connectivity to an additional PDN over E-UTRAN including allocation of a default bearer, if the 
UE already has active PDN connections over E-UTRAN. This procedure is also used to request for connectivity to an 
additional PDN over E-UTRAN, if the UE is simultaneously connected to E-UTRAN and a non-3GPP access and the 
UE already has active PDN connections over both accesses. The PDN connectivity procedure may trigger one or 
multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that UE. 

An emergency attached UE shall not initiate any PDN Connectivity Request procedure. A normal attached UE shall 
request a PDN connection for emergency services when Emergency Service is required and an emergency PDN 
connection is not already active. 



£75/ 



3GPP TS 23.401 version 10.3.0 Release 10 



206 



ETSI TS 123 401 V1 0.3.0 (2011-03) 



UE 



eNodeB 



MME 



1 . PDN Connect 



vity Request 



7. Bearer Setup Request / PDN Connect vity Accept 



8. RRC Connection Reconfiguratior 



9. RRC Connec tion Reconfiguratior Complete 



11. Direct Transfer 

► 



10. Bearer Setup Flesponse 



12. PDN Connectivity Complete 



First Uplink Data 



First DDwnllnl< Data 



Serving GW PDN GW 



2. Create Session Request 



6. Create Session F^esponse 



13. Modify Bearer Fj equest 



13.a 
IS.b 



14. Modify Bearer R esponse 



15. Notify Request 

1 6. Notify Respo 



PCRF 



3. Create Se ssion Request 



HSS 



(A) 



4. IP-CAN Session 

Establishment/Modlflcatldn 



, 5. Create Session Response 



First Downlink Data 



Modify Bearer request 

► (B) 

Modify Bearer response 



nse 



NOTE 1: 



Figure 5.10.2-1: UE requested PDN connectivity 

For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4, 5 and 13a/b 
concern GTP based S5/S8. 



NOTE 2: The UE also uses this procedure to request re-establishment of existing PDN connectivity upon handover 
from non-3GPP accesses. 

NOTE 3: The steps in (B) are executed only upon handover from non-3GPP access. 

1 . The UE initiates the UE Requested PDN procedure by the transmission of a PDN Connectivity Request (APN, 
PDN Type, Protocol Configuration Options, Request Type) message. If the UE was in ECM-IDLE mode, this 
NAS message is preceded by the Service Request procedure. PDN type indicates the requested IP version (IPv4, 
IPv4v6, IPv6). The MME verifies that the APN provided by UE is allowed by subscription. If the UE did not 
provide an APN, the MME shall use the APN from the default PDN subscription context, and, use this APN for 
the remainder of this procedure. Protocol Configuration Options (PCO) are used to transfer parameters between 
the UE and the PDN GW, and are sent transparently through the MME and the Serving GW. The Protocol 
Configuration Options may include the Address Allocation Preference, which indicates that the UE prefers to 
obtain an IPv4 address only after the default bearer activation by means of DHCPv4. If the UE has UTRAN or 
GERAN capabilities, it shall send the NRSU in the PCO to indicate the support of the network requested bearer 
control in UTRAN/GERAN. The Request Type indicates "initial request" if the UE requests new additional PDN 
connectivity over the 3GPP access network for multiple PDN connections, the Request Type indicates 
"handover" when the UE is performing a handover from non-3GPP access and the UE has already established 
connectivity with the PDN over the non-3GPP access. 
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The UE shall indicate Request Type "Emergency" when it requests a PDN connection for emergency services. 

If the message is being sent via a HeNB which has a collocated L-GW, it includes the L-GW address in the 
Uplink NAS transport message to the MME. 

2. If the MME receives a PDN Connectivity Request from an emergency attached UE or the PDN Connectivity 
Request is for normal services and the mobility or access restrictions do not allow the UE to access normal 
services the MME shall reject this request. 

If the Request Type indicates "Emergency" and the MME is not configured to support PDN connections for 
emergency services the MME shall reject the PDN Connectivity Request with an appropriate reject cause. 

If the Request Type indicates "Emergency", the MME derives a PDN GW from the MME Emergency 
Configuration Data or the MME selects a PDN GW as described in clause 4.3.12.4 on PDN GW Selection 
Function (3GPP accesses) according to the Emergency APN in the MME Emergency Configuration Data. This 
selection shall provide a PDN GW from visited PLMN only. 

If the Request Type indicates "Emergency" and the MME is configured to support PDN connections for 
emergency services, it uses the MME Emergency Configuration Data for the bearer establishment in this step 
and ignores any subscription data limitation. 

If the Request Type indicates "Handover", the MME uses the PDN GW stored in the Subscription Data retrieved 
by the MME during the Update Location performed at attach. If the Request Type indicates "initial request" the 
MME selects a PDN GW as described in clause 4.3.8.1 on PDN GW Selection Function (3GPP accesses). 

If the UE provided APN is authorized for LIPA according to the user subscription, the MME shall use the CSG 
Subscription Data to authorize the connection. 

The MME allocates a Bearer Id, and sends a Create Session Request (IMSI, MSISDN, MME TEID for control 
plane, RAT type, PDN GW address, PDN Address, Default EPS Bearer QoS, PDN Type, subscribed APN- 
AMBR, APN, EPS Bearer Id, Protocol Configuration Options, Handover Indication, ME Identity, User Location 
Information (ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication. 
Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum 
APN Restriction, Dual Address Bearer Flag) message to the Serving GW. 

The RAT type is provided in this message for the later PCC decision. The MSISDN is included if the MME has 
it stored for that UE. Handover Indication is included if the Request Type indicates "handover". Selection Mode 
indicates whether a subscribed APN was selected, or a non-subscribed APN sent by the UE was selected. The 
P-GW may use Selection Mode when deciding whether to accept or reject the default bearer activation. For 
example, if an APN requires subscription, the P-GW is configured to accept only the default bearer activation 
that requests a subscribed APN as indicated by Selection Mode. Charging Characteristics indicates which kind of 
charging the bearer context is liable for. 

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of 
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [44]. 
The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace 
is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information 
received from the HLR or OMC. 

The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer 
context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 
of TS 23.060 [7]). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the 
Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer 
context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with 
sending an appropriate error cause to the UE. 

If the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in 
the PDN address. The MME may change the requested PDN type according to the subscription data for this APN 
as described in clause 5.3.1.1. The MME shall set the Dual Address Bearer Flag when the PDN type is set to 
IPv4v6 and all SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, 
which is determined based on node pre-configuration by the operator. 

3. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, 
MSISDN, Serving GW Address for the user plane. Serving GW TEID of the user plane. Serving GW TEID of 
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the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR, 
APN, Bearer Id, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information 
(ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication. Selection Mode, 
Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, 
Dual Address Bearer Flag) message to the PDN GW indicated in the PDN GW address received in the previous 
step. After this step, the Serving GW buffers any downlink packets it may receive from the PDN GW until 
receives the message in step 13 below. The MSISDN is included if received from the MME. If the Handover 
Indication is included, the Serving GW includes it in the Create Session Request message. 

P-GWs shall not perform any checks of Maximum APN Restriction if Create Default Bearer Request includes 
emergency APN. 

4. If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW may employ an IP-CAN 
Session Establishment procedure as defined in TS 23.203 [6] with the PCRF to get the default PCC rules for the 
UE. This may lead to the establishment of a number of dedicated bearers following the procedures defined in 
clause 5.4. 1 in association with the establishment of the default bearer which is described in Annex F. 

The RAT type is provided to the PCRF by the PDN GW if received by the previous message. If the PDN 
GW/PCEF is configured to activate predefined PCC rules for the default bearer, the interaction with the PCRF is 
not required (e.g. operator may configure to do this) at the moment. 

The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP) associated with the default 
bearer in the response to the PDN GW as defined in TS 23.203 [6]. 

If the PCC is configured to support emergency services and dynamic PCC is deployed, the PCRF, based on the 
Emergency APN, sets the ARP of the PCC rules to a value that is reserved for emergency services and the 
authorization of dynamic PCC rules as described in TS 23.203 [6]. If dynamic PCC is not deployed, the PDN 
GW is configured to set the ARP to a value that is reserved for emergency services. 

If dynamic PCC is deployed and the Handover Indication is present, the PDN GW executes a PCEF-Initiated 
IP-CAN Session Modification procedure with the PCRF as specified in TS 23.203 [6] to report the new IP-CAN 
type. Depending on the active PCC rules, the establishment of dedicated bearer for the UE may be required. The 
establishment of those bearers shall take place in combination with the default bearer activation as described in 
Annex F. This procedure can continue without waiting for a PCRF response. If changes to the active PCC rules 
are required, the PCRF may provide them after the handover procedure is finished. 

In both cases (Handover Indication is present or not), if dynamic PCC is not deployed, the PDN GW may apply 
local QoS policy. This may lead to the establishment of a number of dedicated bearers for the UE following the 
procedures defined in clause 5.4.1 in combination with the establishment of the default bearer, which is 
described in Annex F. 

If the CSG information reporting triggers are received from the PCRF, the PDN GW should set the CSG 
Information Reporting Action IE accordingly. 

5. The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows 
the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The 
way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251 [44]. 

The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the 
user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Id, EPS Bearer QoS, 
Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info 
Change Reporting Action (Start) (if the PDN GW decides to receive UE's location information during the 
session), CSG Information Reporting Action (Start) (if the PDN GW decides to receive UE's User CSG 
information during the session), APN-AMBR) message to the Serving GW. The PDN GW takes into account the 
received PDN type, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the 
PDN type to be used as follows. If the received PDN type is IPv4v6 and both IPv4 and IPv6 addressing are 
possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing for this 
APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the received PDN 
type is IPv4 or IPv6, the PDN GW uses the PDN type if it is supported in the PDN, otherwise an appropriate 
error cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN Type If the 
PDN GW has selected a PDN type different from the received PDN Type, the PDN GW indicates together with 
the PDN type IE a reason cause to the UE why the PDN type has been modified, as described in clause 5.3.1.1. 
PDN Address may contain an IPv4 address for IPv4 and/or an IPv6 prefix and an Interface Identifier. If the PDN 
has been configured by the operator so that the PDN addresses for the requested APN shall be allocated by usage 
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of DHCPv4 only, or if the PDN GW allows the UE to use DHCPv4 for address allocation according to the 
Address Allocation Preference received from the UE, the PDN Address shall be set to 0.0.0.0, indicating that the 
IPv4 address shall be negotiated by the UE with after completion of the Default Bearer Activation procedure. 
For external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the external PDN using either 
RADIUS or Diameter client function. In the PDN Address field of the Create Session Response, the PDN GW 
includes the Interface Identifier and IPv6 prefix. The PDN GW sends Router Advertisement to the UE after 
default bearer establishment with the IPv6 prefix information for all cases. If the PDN address is contained in the 
Create Session Request, the PDN GW shall allocate the IPv4 address and/or IP6 prefix contained in the PDN 
address to the UE. If Handover Indication indicates "Handover", the PDN Address Information shall contain the 
same IP address the UE obtained during PDN connectivity establishment over the non-3GPP access. The PDN 
GW derives the BCM based on the NRSU and operator policy. Protocol Configuration Options contains the 
BCM as well as optional PDN parameters that the P-GW may transfer to the UE. These optional PDN 
parameters may be requested by the UE, or may be sent unsolicited by the P-GW. Protocol Configuration 
Options are sent transparently through the MME. 

When the Handover Indication is present, the PDN GW does not yet send downlink packets to the S-GW; the 
downlink path is to be switched at step 13a. 

If the PDN GW is an L-GW, it does not forward downlink packets to the S-GW. The packets will only be 
forwarded to the HeNB at step 10 via the direct user plane path for Local IP Access. 

6. If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are 
received for this bearer context, then the S-GW shall store this for the bearer context and the S-GW shall report 
to that P-GW whenever a UE's Location Information and/or User CSG Information change occurs that meets the 
P-GW request, as described in clause 15.1.1a of TS 23.060 [7]. 

The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User 
Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Id, EPS Bearer QoS, 
PDN GW address and TEID (GTP-based S5/S8) or GRE key (PMIP-based S5/S8) at the PDN GW for uplink 
traffic. Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS Info 
Change Reporting Action (Start), CSG Information Reporting Action (Start), APN-AMBR) message to the 
MME. The DL TFT for PMIP-based S5/S8 is obtained from interaction between the Serving GW and the PCRF 
as described in clause 5.6.1 of TS 23.402 [2], when PCC is deployed; otherwise, the DL TFT IE is wildcarded, 
matching any downlink traffic. If the UE indicates the Request Type as "Handover", this message also serves as 
an indication to the MME that the S5/S8 bearer setup and update has been successful. At this step the GTP 
tunnel(s) over S5/S8 are established. 

7. If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall 
check this received value with the stored value for the Maximum APN Restriction to ensure there are no 
conflicts between values. If the consequence of this check results in the PDN connectivity being rejected, the 
MME shall initiate a Bearer Deactivation and return an appropriate error cause. If the PDN Connectivity Request 
is accepted, the MME shall determine a (new) value for the Maximum APN Restriction. If there is no previously 
stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the 
received APN Restriction. 

The P-GW shall ignore Maximum APN restriction if the request includes the Emergency APN. 

For emergency service MME shall not deactivate bearer(s), if present, to maintain valid APN restriction 
combination. 

If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are 
received for this bearer context, then the MME shall store this for the bearer context and the MME shall report 
whenever a UE's Location Information and/or User CSG Information change occurs that meets the request, as 
described in clause 15.1.1a of TS 23.060 [7]. 

The MME may need to modify the UE AMBR, which has been assigned to the eNodeB, based on the subscribed 
UE-AMBR and the updated set of APN-AMBRs in use. The principles to determine the UE-AMBR are 
described in clause 4.7.3. 

The MME sends PDN Connectivity Accept (APN, PDN Type, PDN Address, EPS Bearer Id, Session 
Management Request, Protocol Configuration Options) message to the UE. This message is contained in an 
S1_MME control message Bearer Setup Request (EPS Bearer QoS, UE-AMBR, PDN Connectivity Accept, Sl- 
TEID) to the eNodeB. This SI control message includes the TEID at the Serving GW used for user plane and the 
address of the Serving GW for user plane. In addition, if the PDN connection is established for Local IP Access, 
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the S 1 control message includes a Correlation ID for enabling the direct user plane path between the HeNB and 
the L-GW. 

NOTE 4: In this release of the 3GPP specification the Correlation ID is set equal to the user plane PDN GW TEID 
(GTP -based S5) or GRE key (PMIP-based S5) that the MME has received in step 6. 

In the PDN Connectivity Accept message, the MME does not include the IPv6 prefix within the PDN Address. 
The MME includes the APN-AMBR and the EPS Bearer QoS parameter QCI into the Session Management 
Request. Furthermore, if the UE has UTRAN or GERAN capabilities and the network supports mobility to 
UTRAN or GERAN, the MME uses the EPS bearer QoS parameters to derive the corresponding PDP context 
parameters QoS Negotiated (R99 QoS profile). Radio Priority, Packet Flow Id and TI and includes them in the 
Session Management Request. If the UE indicated in the UE Network Capability that it does not support BSS 
packet flow procedures, then the MME shall not include the Packet Flow Id. MME will not send the S 1 Bearer 
Setup Request message until any outstanding SI Bearer Setup Response message for the same UE has been 
received or timed out. If the APN-AMBR has changed the MME may update the UE-AMBR if appropriate. 

If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as 
described in clause 5.3.1.1. 

8. The eNodeB sends RRC Connection Reconfiguration to the UE including the PDN Connectivity Accept 
message. The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the 
Session Management Request IE, for use when accessing via GERAN or UTRAN. The UE may provide EPS 
Bearer QoS parameters to the application handling the traffic flow. The application usage of the EPS Bearer QoS 
is implementation dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the 
EPS Bearer QoS parameters contained in the Session Management Request. 

If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address with DHCPv4 as specified in 
TS 29.061 [38], If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from 
the network with the IPv6 prefix information or it may send a Router Solicitation if necessary. 

NOTE 5: The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation". 

9. The UE sends the RRC Connection Reconfiguration Complete to the eNodeB. 

10. The eNodeB send an Sl-AP Bearer Setup Response to the MME. The Sl-AP message includes the TEID of the 
eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point. 

If the Correlation ID is included in the Bearer Setup Request, the eNodeB shall use the included information to 
establish a direct user plane path to the L-GW and forward uplink data for Local IP Access accordingly. 

1 1 . The UE NAS layer builds a PDN Connectivity Complete message including EPS Bearer Identity. The UE then 
sends a Direct Transfer (PDN Connectivity Complete) message to the eNodeB. 

12. The eNodeB sends an Uplink NAS Transport (PDN Connectivity Complete) message to the MME. 

After the PDN Connectivity Accept message and once the UE has obtained a PDN Address Information, the UE 
can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN 
GW. If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was granted a single address 
PDN type (IPv4 or IPv6) by the network with a reason cause indicating that only single IP version per PDN 
connection is allowed, the UE should request for the activation of a parallel PDN connection to the same APN 
with a single address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no reason 
cause in step 8 in response to a IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4 
address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDN was successful. 
It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send 
Router Solicitation if necessary. 

13. Upon reception of the Bearer Setup Response message in step 10 and the PDN Connectivity Complete message 
in step 12, the MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, 
Handover Indication) message to the Serving GW. If Request Type indicates "handover", the Handover 
Indication is also included. 

13a. If the Handover Indication is included in step 13, the Serving GW sends a Modify Bearer Request (Handover 
Indication) message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to 
3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated 
EPS bearers established. 
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13b. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW. 

14. The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) to the MME. The 
Serving GW can then send its buffered downlink packets. 

15. After the MME receives Modify Bearer Response in step 14, if Request type does not indicate handover and an 
EPS bearer was established and if the subscription data indicates that the user is allowed to perform handover to 
non-3GPP accesses and if this is the first PDN connection associated with this APN and if the MME selected a 
PDN GW that is different from the PDN GW identity which was previously indicated by the HSS in the PDN 
subscription context, the MME shall send a Notify Request including the PDN GW address and the APN to the 
HSS for mobility with non-3GPP accesses. The message shall include information that identifies the PLMN in 
which the PDN GW is located. 

If the Request Type of the UE requested connectivity procedure indicates "Emergency", the MME shall not send 
any Notify Request to the HSS. 

16. The HSS stores the PDN GW identity and the associated APN, and sends a Notify Response to the MME. 

NOTE 6: For handover from non-3GPP access, the PDN GW initiates resource allocation deactivation procedure in 
the trusted/untrusted non-3GPP IP access as specified in TS 23.402 [2]. 

5.1 0.3 UE or MME requested PDN disconnection 

The UE or MME requested PDN disconnection procedure for an E-UTRAN is depicted in figure 5.10.3-1. The 
procedure allows the UE to request for disconnection from one PDN. Bearers including the default bearer of this PDN 
shall be deleted during this procedure. The procedure also allows the MME to initiate the release of a PDN connection. 

This procedure is also used as part of the SIPTO function when the MME determines that GW relocation is desirable. In 
this situation the MME deactivates the relevant PDN connection(s) using the "reactivation requested" cause value, and 
the UE should then re-establish those PDN connection(s). 

NOTE 1: The deactivation with reactivation requested does not work with pre-Rel-9 LTE UEs. 

This procedure is not used to terminate the last PDN connection. The UE uses the UE-initiated Detach procedure in 
clause 5.3.8.2 to disconnect the last PDN connection. The MME uses the MME-initiated Detach procedure in 
clause 5.3.8.3 to release the last PDN connection. 



£75/ 



3GPP TS 23.401 version 10.3.0 Release 10 



212 



ETSI TS 123 401 VI 0.3.0 (2011-03) 



UE 



eNodeB 



MME 



Serving GW PDN GW PCRF HSS 



1a. PDN Disconnection Request 



8. RRG Connettion 
< 



10a. Direct Trc.nsfer 



lb PDN disconnection trigger 



2. Delete Session Request 



3. Delete Session Request 



(A) 



4. Delete Session Response 



5. IP-CAN Session termination 



6. Delete Session Response 



7. Deactivate Bearer Request 



Reconfiguration 
9a. RRG Gonnection Reconfiguration Gomplete 
9b. Deactivate Bearer Response 



10b. Deactivate EPS Bearer Gontext Accept 



Figure 5.10.3-1 : UE or MME requested PDN disconnection 

NOTE 2: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4 and 5 concern GTP 
based S5/S8. 

1. The procedure is triggered by either step la or step lb. 

la. The UE initiates the UE requested PDN disconnection procedure by the transmission of a PDN 

Disconnection Request (LBI) message. The LBI indicates the default bearer associated with the PDN 
connection being disconnected. If the UE was in ECM-IDLE mode, this N AS message is preceded by the 
Service Request procedure. 

lb. The MME decides to release the PDN connection. This may be e.g. due to change of subscription or lack of 
resources or due to SIPTO. If the UE is in ECM-IDLE state and the reason for releasing PDN connection is 
"reactivation requested" e.g. due to SIPTO, the MME initiates paging via Network Triggered Service 
Request procedure in clause 5.3.4.3 from step 3a onwards in order to inform UE of the request. 

2. The EPS Bearers in the Serving GW for the particular PDN connection are deactivated by the MME by sending 
Delete Session Request (Cause, LBI) to the Serving GW. This message indicates that all bearers belonging to 
that PDN connection shall be released. If the PDN GW requested UE's location info (determined from the UE 
context), the MME also includes the User Location Information IE in this message. If the UE Time Zone has 
changed, the MME includes the UE Time Zone IE in this message. 

3. The Serving GW sends Delete Session Request (Cause, LBI) to the PDN GW. The S-GW also includes User 
Location Information IE and/or UE Time Zone IE if it is present in step 2. 

4. The PDN GW acknowledges with Delete Session Response. 

5. The PDN GW employs the PCEF-initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6] 
to indicate to the PCRF that the IP -CAN session is released if PCRF is applied in the network. 

6. The Serving GW acknowledges with Delete Session Response. 

7. If the UE is in ECM IDLE state and the PDN disconnection is decided by the MME, the MME shall delete the 
corresponding contexts of the PDN connection locally, steps 7 to 10b are skipped. The MME initiates the 
deactivation of all Bearers associated with the PDN connection to the eNodeB by sending the Deactivate Bearer 
Request message to the eNodeB. The MME shall re-calculate the UE-AMBR (see clause 4.7.3). This Sl-AP 
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message carries the list of EPS bearers to be released, the new UE-AMBR, and a NAS Deactivate EPS Bearer 
Context Request (LBI) message. The MME builds a NAS message Deactivate EPS Bearer Context Request 
including the EPS Bearer Identity, and includes it in the Sl-AP Deactivate Bearer Request message. 

If the network wants to trigger GW relocation (e.g. for SIPTO), the NAS message Deactivate EPS Bearer 
Context Request includes the request for reactivation of the same PDN connection via the same APN by the UE. 

NOTE 3: If the UE is in ECM-IDLE state and the PDN disconnection is decided by the MME, the EPS bearer state 
is synchronized between the UE and the network at the next ECM-IDLE to ECM-CONNECTED 
transition (e.g. Service Request or TAU procedure). 

8. The eNodeB sends the RRC Connection Reconfiguration message including the corresponding bearers to be 
released and the NAS Deactivate EPS Bearer Context Request (LBI) message to the UE. 

9a. The UE releases all resources corresponding to the PDN connection and acknowledges this by sending the RRC 
Connection Reconfiguration Complete message to the eNodeB. 

9b. The eNodeB sends an acknowledgement of the deactivation to the MME. 

10a. The UE NAS layer builds a Deactivate EPS Bearer Context Accept message. The UE then sends a Direct 
Transfer (Deactivate EPS Bearer Context Accept) message to the eNodeB. 

If the Deactivate EPS Bearer Context Request message from the MME indicated reactivation requested, the UE 
starts the UE initiated PDN connection request procedure as specified in clause 5.10.2 by using the same APN of 
the released PDN connection. 

10b. The eNodeB sends an Uplink NAS Transport (Deactivate EPS Bearer Context Accept) message to the MME. 

The MME determines the Maximum APN Restriction for the remaining PDN connections and stores this new value for 
the Maximum APN Restriction. 

5.11 UE Capability Handling 

5.11.1 General 

The UE Capability information is made up of the UE Radio Capability information and the UE Core Network 
Capability information. 

5.1 1 .2 UE Radio Capability Handling 

The UE Radio Capability information contains information on RATs that the UE supports (e.g. power class, frequency 
bands, etc). Consequently, this information can be sufficiently large (e.g. >50 octets) that it is undesirable to send it 
across the radio interface at every transition from ECM-IDLE to ECM-CONNECTED. To avoid this radio overhead, 
the MME stores the UE Capability information during ECM-IDLE state and the MME shall, if it is available, send its 
most up to date UE Radio Capability information to the E-UTRAN in the SI interface INITIAL CONTEXT SETUP 
REQUEST message unless the UE is performing an Attach procedure or a Tracking Area Update procedure for the 
"first TAU following GERAN/UTRAN Attach" or for a "UE radio capability update". 

NOTE 1: For a GERAN/UTRAN/E-UTRAN capable UE, the UE Radio Capability information that the MME 
stores is broadly equivalent to the combination of the MS Radio Access capability sent in the 
TS 24.008 [47] Attach Request or RAU Request messages plus the E-UTRAN Inter RAT Handover 
information sent in the TS 24.008 [47] Attach Complete or RAU Complete messages. The UTRAN Radio 
Capabilities are excluded owing to issues with the handling of dynamic UMTS security parameters. 

If the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following 
GERAN/UTRAN Attach" or for "UE radio capability update", the MME shall delete (or mark as deleted) any UE Radio 
Capability information that it has stored, and, if the MME sends an SI interface INITIAL CONTEXT SETUP 
REQUEST message during that procedure, the MME shall not send any UE Radio Capability information to the 
E-UTRAN in that message. This triggers the E-UTRAN to request the UE Radio Capability from the UE and upload it 
to the MME in the SI interface UE CAPABILITY INFO INDICATION message. 
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If the UE is performing a Service Request (or other) procedure and the MME does not have UE Radio Capability 
information available (or it is available, but marked as "deleted"), then the MME sends an S 1 interface INITIAL 
CONTEXT SETUP REQUEST message to the E-UTRAN without any UE Radio Capability information in it. This 
triggers the E-UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S 1 interface 
UE CAPABILITY INFO INDICATION message. 

NOTE 2: This use of the INITIAL CONTEXT SETUP REQUEST message means that for a signalling only 

procedure such as a periodic Tracking Area Update, the UE Radio Capability would not be sent to the 
E-UTRAN. 

NOTE 3: If a "first TAU following GERAN/UTRAN Attach" Tracking Area Update is performed during ECM- 
CONNECTED mode, e.g. after an inter RAT handover, no INITIAL CONTEXT SETUP REQUEST is 
sent and the UE Radio Capability information in the MME will remain deleted until the next ECM-IDLE 
to ECM-CONNECTED transition (or later, e.g. if the next activity from the UE is another Tracking Area 
Update). 

The UE Radio Capability is not provided directly from one CN node to another. It will be uploaded to the MME when 
the E-UTRAN requests the UE Radio Capability information from the UE. 

During handover via the MME (both intra RAT and inter RAT), the radio capability information for the source and 
target 3GPP RATs (with the possible exception of UTRAN) are transferred in the "source to target transparent 
container". Information on additional 3GPP RATs is optionally transferred in the "source to target transparent 
container". Transfer of the radio capability information related to the source and/or additional RATs is beneficial as it 
avoids the need for the target RAT to retrieve the information from the UE prior to a subsequent inter-RAT handover. 

Owing to issues with dynamic UTRAN security parameters, special rules apply to the handling of the UTRAN radio 
capability information at inter-RAT handover (see e.g. the HandoverPreparationlnformation message description in 
TS 36.331 [37] and the usage of the PS Handover Complete Ack message in TS 43.129 [8] and TS 48.018 [42]) 

To allow for the addition of future radio technologies, frequency bands, and other enhancements, the MME shall store 
the UE Radio Capability Information even if it is larger than specified in TS 36.331 [37], up to a maximum size of 
510 octets. 

NOTE 4: The 510 octet value comes from the information element encoding rules described in TS 24.007 [45] and 
the assumption that the information contained within this UE Radio Capability Information Element 
stored by the MME is the equivalent of information signalled in two information elements in the GERAN 
NAS signalling for the case of GERAN to E-UTRAN PS handover. 

The E-UTRAN stores the UE Radio Capability information, received in the SI interface INITIAL CONTEXT SETUP 
REQUEST message or obtained from the UE, for the duration of the RRC connection for that UE. Before any handover 
attempt from E-UTRAN to UTRAN, the E-UTRAN retrieves the UE's UTRAN Radio Capabilities from the UE. 

If the UE's non-UTRAN UE Radio Capability information changes while in ECM-IDLE state (including cases of being 
in GERAN/UTRAN coverage), the UE shall perform a Tracking Area Update indicating "UE radio capability update" 
when it next returns to E-UTRAN coverage. 

NOTE 5: In this release of the specifications, "UE radio capability update" is only supported for changes of 

GERAN radio capabilities in ECM-IDLE. Any change in the UE's E-UTRAN capabilities requires the 
UE to detach and then re-attach to the system. 



5.1 1 .3 UE Core Network Capability 



The UE Core Network Capability is split into the UE Network Capability IE (mostly for E-UTRAN access related core 
network parameters) and the MS Network Capability IE (mostly for UTRAN/GERAN access related core network 
parameters) and contains non radio-related capabilities, e.g. the NAS security algorithms etc. Both the UE Network 
Capability and the MS Network Capability are transferred between CN nodes at MME to MME, MME to SGSN, SGSN 
to SGSN, and SGSN to MME changes. 

In order to ensure that the UE Core Network Capability information stored in the MME is up to date (e.g. to handle the 
situation when the USIM is moved into a different device while out of coverage, and the old device did not send the 
Detach message; and the cases of inter-RAT Tracking Area Update), the UE shall send the UE Core Network 
Capability information to the MME during the Attach and non-periodic Tracking Area Update procedure within the 

NAS message. 
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The MME shall store always the latest UE Core Network Capability received from the UE. Any UE Core Network 
Capability that an MME receives from an old MME/SGSN is replaced when the UE provides the UE Core Network 
Capability with the Tracking Area Update signalling. 

If the UE's UE Core Network Capability information changes (in either ECM -CONNECTED or in ECM-IDLE state 
(including cases of being in GERAN/UTRAN coverage and having ISR activated)), the UE shall perform a Tracking 
Area Update ('type' different to 'periodic') when it next returns to E-UTRAN coverage - see clause 5.3.3.0. 

To allow for the addition of future features, the MME shall store the UE Network Capability and the MS Network 
Capability even if either or both is larger than specified in TS 24.008 [47]/TS 24.301 [46], up to a maximum size of 
32 octets for each IE. 

5.12 Warning message delivery 

5.12.1 General 

Warning message delivery is similar to Cell Broadcast Service defined in TS 23.041 [48], it permits a number of 
unacknowledged Warning messages to be broadcast to UEs within a particular area. 

The maximum size of the Warning message for E-UTRAN is different from that of UTRAN/GERAN. 

When SI -flex is used, the eNodeB may receive duplicated Warning messages. Duplicated messages can be detected by 
checking the message identifier and serial number fields and they shall not be transmitted on the radio interface. 

5.12.2 Warning message delivery procedure 

The Warning message to be broadcast is delivered via MMEs to multiple eNodeBs. The eNodeB(s) are responsible for 
scheduUng the broadcast of the new message and the repetitions in each cell. 

The overall warning message delivery procedure is presented in figure 5.12.2.1-1: 
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Figure 5.12.2.1-1 : Warning message delivery procedure 
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0. Device Management is used to configure the UE with a list of PLMNs that wish the UE to accept primary 
notification "without security". By defauh, the Hst in the UE shall be empty (i.e. the default setting shall be that 
security is needed for all PLMNs). 

Network registration and Security (e.g. mutual authentication) procedures are performed. The UE stores a flag 
that indicates whether or not it has authenticated the network. If security is applied to warning message delivery 
then to guard against replay attacks, at least one of the core network nodes (MME, SGSN, MSC) shall use the 
Network Information and Time Zone (NITZ) feature as specified in TS 22.042 [49], TS 24.008 [47] and 
TS 24.301 [46] to send the current Time of Day to the UE. The UE shall synchronise an internal Emergency 
Warning System clock to the UTC time supplied in this procedure. The UE's internal Emergency Warning 
System clock shall be accurate to within 5 minutes over a period of 1 month. The network shall ensure that the 
accuracy of the NITZ time information when it arrives at the MS is within 5 minutes. The NITZ procedure shall 
be used to synchronise the UE's internal Emergency Warning System clock each time a UE is attached to a 
network, and it is the responsibility of the network to ensure that it is refreshed at least once a month if a UE is 
continually attached. 

NOTE 1: This step is performed each time a UE is attached to a network (e.g. after each power on). 

1. CBE (e.g. Information Source such as PSAP or Regulator) sends emergency information (e.g. "warning type", 
"warning message", "impacted area", "time period") to the CBC. The CBC shall authenticate this request. 

NOTE 2: The interface between CBE and CBC is out of 3GPP scope. 

2. Using the "impacted area" information, the CBC identifies which MMEs need to be contacted and determines 
the information to be place into the Warning Area Information Element. The CBC sends a Write-Replace 
Warning Request message containing the Warning message to be broadcast and the delivery attributes (Message 
identifier. Serial Number, Tracking Area ID list. Warning Area, OMC ID, CWM Indicator) to MMEs. 

For the definition of Message ID and Serial Number, see the definitions for Message ID and Serial Number in 
TS 23.041 [48]. 

The warning messages use the coding scheme for CBS data specified in TS 23.038 [54]. 

The Tracking Area ID list is only used by the MME. The MME uses it for selecting which eNodeBs to forward 
the Write-Replace Warning Request message to. 

The Warning Area shall be a list of Cell IDs and/or a list of TAIs and/or one or more Emergency Area IDs. The 
Warning Area is only used by the eNodeB. The eNodeB is configured with the TAI(s) and Cell ID(s) it serves 
and the Emergency Area ID(s) that it belongs to. The eNodeB checks for any match of the contents of the 
Warning Area with these IDs to identify the cells where to distribute the warning message. The Warning Area is 
an optional information element. If the Warning Area is absent, it shall be interpreted as "all cells on the 
eNodeB". The number of cell IDs will be limited by the message size on SBc and Sl-MME. An Emergency 
Area ID is unique within the PLMN. 

The message may include an OMC ID. If present, it indicates the OMC to which the Trace record generated in 
step 8 is destined. Co-location of that OMC with the CBC is an operator option. 

CBC shall set the Concurrent Warning Message (CWM) indicator in all Write-Replace Warning Request 
messages, if the PLMN supports concurrent warning message broadcasts. 

Unless they are not used by that PLMN, the "digital signature" and "timestamp" information are transmitted 
within the "Warning message". 

3. The MME sends a Write-Replace Warning Confirm message that indicates to the CBC that the MME has started 
to distribute the warning message to eNodeBs. 

If this message is not received by the CBC within an appropriate time period, the CBC can attempt to deliver the 
Warning message via another MME in the same pool area. 

4. Upon reception of the Write-Replace Confirm messages from the MMEs, the CBC may confirm to the CBE that 
the PLMN has started to distribute the warning message. 

NOTE 3: CBC reports also from GERAN and UTRAN success/failure, however GERAN, UTRAN are out of scope 
of this clause. 
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NOTE 4: The interface between CBE and CBC is out of 3GPP scope. 

5. The MME forwards Write-Replace Warning Message Request to eNodeBs. The MME shall use the Tracking 
Area ID list to determine the eNodeBs in the delivery area. If the Tracking Area ID list is empty the message is 
forwarded to all eNodeBs that are connected to the MME. 

6. When SI -flex is used the eNodeB may receive same message from multiple MMEs. The eNodeB detects 
duplicate messages by checking the message identifier and serial number fields within the Warning Message. If 
any redundant messages are detected only the first one received will be broadcasted by the cells. The eNodeB 
shall use the Warning Area information to determine the cell(s) in which the message is to be broadcast. The 
eNodeBs return a Distribute Warning Message Response to the MME, even if it was a duplicate. 

If there is a warning broadcast message already ongoing and the CWM Indicator is included in the Write- 
Replace Warning Message Request, the eNodeB does not stop existing broadcast message but start broadcasting 
the new message concurrently. Otherwise the eNodeB shall immediately replace the existing broadcast message 
with the newer one. 

NOTE 5: If concurrent warning messages are not supported, this requires the CBE/CBC to take care that 'lower' 
priority warnings are not sent while a higher priority warning is still being sent. 

The eNodeB broadcasts the message frequently according to the attributes set by the CBC that originated the 
Warning Message distribution. 

NOTE 6: The capability of the Warning message broadcast (e.g. maximum number of pages, etc.) should be 
specified consistent with the requirements applicable for UTRAN and GERAN defined in 
TS 23.041 [48]. 

7a. If the UE has been configured to receive primary notification "without security", and the UE has authenticated 
the core network of the eNodeB it is camped on, then the UE can use "warning type" values, 'earthquake', 
'tsunami' or 'earthquake and tsunami', immediately to alert the user. When "warning type" is 'test', the UE silently 
discards the primary notification, but the UE specially designed for testing purposes may proceed with the 
following procedures. 

The UE activates reception of the broadcast messages containing the "warning message". 

If the "digital signature" and "timestamp" are present and security checks fail, then the UE notifies the user of 
this fact and stops the user alerting. 

If both the "digital signature" and "timestamp" are present and security checks pass, then the UE indicates the 
contents of the "warning message" to the user along with an indication that the message has been authenticated. 

In other cases the UE indicates the contents of the "warning message" to the user along with an indication that 
the message has not been authenticated. 

UE shall consider a message duplicated if the combination of "message identifier" and "serial number" matches 
with those of the previous message that was received from the same PLMN. The UE shall ignore the message 
detected as a duplicated. 

For ETWS, the UE shall perform duplicate message detection independently for primary and secondary 
notifications. 

7b. If the UE has not been configured to receive primary notification "without security" on that PLMN, or the UE 
has not authenticated the network, the UE activates reception of the broadcast messages containing the "warning 
message". When "warning type" is 'test', the UE silently discards the primary notification, but the UE specially 
designed for testing purposes may proceed with the following procedures. 

Unless both the "digital signature" and "timestamp" are present and the security checks pass, the UE shall ignore 
the message, return to normal idle mode, and ignore primary notifications for the next X seconds. 

NOTE 7: Repetition period X is subject to regulatory requirements, but, in the absence of these requirements being 
included in the 3GPP specifications, the UE manufacturer may assume a value of 60 seconds. 

If both the "digital signature" and "timestamp" are present and security checks pass, then the UE alerts the user; 
and indicates the contents of the "warning message" to the user along with an indication that the message has 
been authenticated. 
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The network shall use UTC time when constructing the "timestamp". The "timestamp" security check shall only 
pass if the "digital signature" check passes and the "timestamp" in the message is within 10 minutes of the UE's 
internal Emergency Warning System clock. The UE shall save all warning messages received within the 
previous 10 minutes up to a maximum number of N messages, and reject incoming messages that contain the 
same "timestamp" as a currently saved message. 

NOTE 8: The value N is subject to regulatory requirements, but, in the absence of these requirements being 

included in the 3GPP specifications, the UE manufacturer can assume a value of 20. A value of 20 would 
mean that up to 20 genuine warning messages can be sent to the same UE within a period of 10 minutes. 
If more than 20 genuine warning messages are sent within a period of 10 minutes, then it cannot be 
guaranteed that a UE would reject a maliciously replayed warning message. 

UE shall consider a message duplicated if the combination of "message identifier" and "serial number" matches 
with those of the previous message that was received from the same PLMN. The UE shall ignore the message 
detected as a duplicated. 

For ETWS, the UE shall perform duplicate message detection independently for primary and secondary 
notifications. 

8. From the Write-Replace Warning Response messages returned by eNodeB's the MME determines the success or 
failure of the delivery and creates a trace record. Any OMC ID received in step 2 is written to the trace record to 
permit the O&M system to deliver them to the desired destination. 

5.12.3 Warning message cancel procedure 

The cancel warning message delivery procedure takes place when CBE requests to stop the on-going broadcast of 
warning messages. 
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Figure 5.12.3-1 : Warning message cancel procedure 

1. CBE initiates procedure by sending Stop Emergency Broadcast Request (e.g. "Message Identifier and Serial 
Number"), to the CBC. The CBC shall authenticate this request. 

NOTE 1: The interface between CBE and CBC is out of 3GPP scope. 
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2. The CBC identifies which MMEs need to be contacted and determines the information to be place into the 
Warning Area Information Element. The CBC sends a Stop Warning Request message (Message Identifier, 
Serial Number, Tracking Area ID list. Warning Area, OMC ID) to MMEs. 

The message may include an OMC ID. If present, it indicates the OMC to which the Trace record generated in 
step 7 is destined. Co-location of that OMC with the CBC is an operator option. 

3. The MME sends a Stop Warning Confirm message that indicates to the CBC that the MME has started to 
distribute the Stop Warning Request message to eNodeBs. 

If this message is not received by the CBC within an appropriate time period, the CBC can attempt to send Stop 
Warning Request via another MME in the same pool area. 

4. Upon reception of the Stop Warning Confirm messages from the MMEs, the CBC may confirm to the CBE that 
the PLMN has initiated the Warning message cancel procedure. 

NOTE 2: The interface between CBE and CBC is out of 3GPP scope. 

5. The MME forwards Stop Warning Request to eNodeB's. The MME shall use the Tracking Area ID list to 
determine the eNodeBs that may have warning message broadcast ongoing. In case the Tracking Area ID list is 
empty the Stop Warning Request is forwarded to all eNodeBs that are connected to the MME. 

6. The eNodeB shall stop broadcasting the warning message identified by the Message Identifier and Serial 
Number in the areas identified by Warning Area IDs. If the Warning Area is absent, it shall be interpreted as "all 
cells on the eNodeB"). 

When S 1 -Flex is used the eNodeB may receive same Stop Warning Request from multiple MMEs, if any 
redundant Stop Warning Requests are detected only the response to the first MME shall contain statistics related 
to the cancelled broadcast. 

7. From the Stop Warning Response messages returned by eNodeB's the MME creates a trace record (e.g. number 
of times a particular message has been broadcasted in a given warning area) related to the cancelled message. 
Any OMC ID received in step 2 is written to the trace record to permit the O&M system to deliver them to the 
desired destination. 

5.13 Discontinuous Reception and UE Specific DRX Parameter 
handling 

During the Attach procedure in E-UTRAN, UTRAN and/or GERAN, the UE signals its UE Specific DRX Parameters 
to the Core Network (MME in the E-UTRAN case and SGSN in UTRAN/GERAN case). 

In E-UTRAN and UTRAN, the UE may signal that it wishes to use the DRX cycle length broadcast in the RAN's 
System Information. Alternatively, the UE can propose a DRX cycle length. The MME shall accept the value proposed 
by the UE. 

In each SI interface Page Request message, the MME shall send the E-UTRAN relevant information from the UE 
Specific DRX Parameters (to help determine the DRX cycle length) and information derived from the IMSI (which 
defines when the UE will be awake from its sleep mode). Details are specified in TS 36.304 [34]. 

NOTE 1: To ease backward compatibiUty with Pre-Release 8 SGSNs, the UTRAN and E-UTRAN DRX cycle 
lengths are encoded in the same field within the TS 24.008 [47] DRX parameter information element. 

At MME to MME, MME to SGSN and SGSN to MME mobility, the UE Specific DRX Parameters are sent from the 
old CN node to the new CN node as part of the MM context information and should not be sent by the UE in the 
Tracking Area Update message. 

NOTE 2: it is assumed that all SGSNs are Release 99 or newer and hence support storage of the Release '99 
encoding of the TS 24.008 [47] DRX parameter information element. 

If a CN node receives UE Specific DRX Parameters in a dedicated message from the UE (e.g. in a Tracking Area 
Update or Attach message), then the CN node updates any stored information with the information supplied by the UE 
and uses the UE provided information in preference to any information that might be received from another CN node 
during the same procedure. 
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If the UE wishes to alter its GERAN or UTRAN/E-UTRAN UE Specific DRX Parameters while in E-UTRAN, then it 
shall send a Tracking Area Update Request message to the MME containing its new UE Specific DRX Parameters. If 
ISR had been activated for the UE, then the UE shall deactivate ISR by setting its TIN to "GUTI" so that the UE 
performs a Routing Area Update when it next enters GERAN/UTRAN coverage. When the UE performs that Routing 
Area Update, the SGSN will receive the updated DRX parameters within the MM context information sent by the MME 
and hence the UE should not include them again in the Routing Area Update Request message. 

If the UE wishes to alter its E-UTRAN/UTRAN or GERAN DRX Parameters while in GERAN or UTRAN coverage, 
then the UE shall send a Routing Area Update Request message to the SGSN containing its new UE DRX Parameters. 
If ISR has been activated, the UE shall deactivate ISR by setting its TIN to "P-TMSI" so that the UE performs a 
Tracking Area Update when it next returns to E-UTRAN coverage. When the UE performs that Tracking Area Update, 
the MME will receive the updated DRX parameters within the MM context information sent by the SGSN and hence 
the UE should not include them again in the Tracking Area Update message. 

5.14 Configuration Transfer procedure 

The purpose of the Configuration Transfer is to enable the transfer of information between two eNodeBs at any time via 
SI interface and the Core Network. An example of application is to exchange the eNodeBs IP addresses in order to be 
able to use X2 interface between the eNodeBs for Self-Optimized Networks (SON), as specified in TS 36.413 [36]. 

5.14.1 Architecture Principles for Configuration Transfer 

Configuration Transfer between two eNodeBs follows the principles used by RAN Information Management (RIM) 
procedures (see clause 5.15) between UTRAN, E-UTRAN and GERAN i.e. providing a generic mechanism for the 
exchange of arbitrary information between applications belonging to the RAN nodes. However Configuration Transfer 
is only used for intra-RAT E-UTRAN information exchange whereas RIM procedures are designed for inter-RAT 
information exchange. Such a separate procedure allows avoiding impacts to other RAT access systems when 
transferred information is added or modified. 

The information is transferred via the MME core network node(s). In order to make the information transparent for the 
Core Network, the information is included in an E-UTRAN transparent container that includes source and target 
eNodeB addresses, which allows the Core Network nodes to route the messages. The mechanism is depicted in 
figure 5.14 1. An example for such transferred information is the SON information, as specified in TS 36.413 [36]. 
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Figure 5.14-1 : inter E-UTRAN Configuration Transfer basic networic architecture 
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The E-UTRAN transparent containers are transferred from the source E-UTRAN node to the destination E-UTRAN 
node by use of Configuration Transfer messages. 

An ENB Configuration Transfer message is used from the eNodeB to the MME over S 1 interface, a MME 
Configuration Transfer message is used from the MME to the eNodeB over S 1 interface, and a Configuration Transfer 
Tunnel message is used to tunnel the E-UTRAN transparent container from a source MME to a target MME over the 
SIO interface. 

Each Configuration Transfer message carrying the E-UTRAN transparent container is routed and relayed independently 
by the core network node(s). Any relation between messages is transparent for the MME, i.e. a request/response 
exchange between applications, for example SON applications, is routed and relayed as two independent messages by 
the MME. An MME supporting the Configuration Transfer procedures provides addressing, routing and relaying 
functions. 

5.14.2 Addressing, routing and relaying 

5.14.2.1 Addressing 

All the Configuration Transfer messages contain the addresses of the source and destination RAN nodes. An eNodeB is 
addressed by the Target eNodeB Identifier. 

5.14.2.2 Routing 

The following description applies to all the Configuration Transfer messages used for the exchange of the E-UTRAN 
transparent container. 

The source RAN node sends a message to its MME including the source and destination addresses. The MME uses the 
destination address to route the message encapsulated in a GTPv2 message to the correct MME via the SIO interface 
(see TS 29.274 [43]). 

The MME connected to the destination RAN node decides which RAN node to send the message to, based on the 
destination address. 

5.14.2.3 Relaying 

The MME performs relaying between GTPv2 messages as described in TS 29.274 [43]. The MME performs relaying 
between SI and SIO messages as described in TS 36.413 [36] and TS 29.274 [43]. 

5.14.2.4 Applications using the Configuration Transfer procedures 

The RAN node applications, which use the Configuration Transfer procedures, are fully transparent for the MME. 
These applications are described in RAN specifications. An example of application is the transfer of information 
required for Self-Optimized Networks (SON). 

5.15 RAN Information Management (RIM) procedures 
5.15.1 General 

The RAN Information Management (RIM) procedures provide a generic mechanism for the exchange of arbitrary 
information between applications belonging to the RAN nodes. The RAN information is transferred via the MME and 
SGSN core network node(s). In order to make the RAN information transparent for the Core Network, the RAN 
information is included in a RIM container that shall not be interpreted by the Core Network nodes. 

The RIM procedures are optional both in the RAN and the CN nodes. For the Gb interface the use of RIM procedures is 
negotiated at start/restart of the Gb link. For the lu interface there is no negotiation of using RIM procedures or not at lu 
link start/restart. 

The RAN information is transferred in RIM containers from the source RAN node to the destination RAN node by use 
of messages. Source and destination RAN nodes can be E-UTRAN, UTRAN or GERAN. Each message carrying the 
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RIM container is routed and relayed independently by the core network node(s). Any relation between messages is 
transparent for the MME/SGSN, i.e. a request/response exchange between RIM applications, for example, is routed and 
relayed as two independent messages by the MME/SGSN. 

The interfaces which will be used are the Gb, the lu, the SI, Gn and the S3 interfaces. The RAN information in the RIM 
container shall be transparent for the Core Network. An MME or SGSN supporting the RIM procedures provides 
addressing, routing and relaying functions. 

5.15.2 Addressing, routing and relaying 

5.15.2.1 Addressing 

All the messages used for the exchange of RAN information contain the addresses of the source and destination RAN 
nodes. A BSS is addressed by Routing Area Identity (RAI) + Cell Identity (CI) of one of its cells. An eNodeB is 
addressed by the Target eNodeB Identifier. An RNC is addressed by Global RNC-Id as defined in TS 23.003 [9]. 

5.15.2.2 Routing 

The following description applies to all the messages used for the exchange of RAN information. 

The source RAN node sends a message to its MME or SGSN including the source and destination addresses. The 
SGSN/MME uses the destination address to route the message encapsulated in a GTP message to the correct 
MME/SGSN via the S3 or Gn interface. 

The MME/SGSN connected to the destination RAN node decides which RAN node to send the message to based on the 
destination address. 

5.15.2.3 Relaying 

The SGSN performs relaying between BSSGP messages, RANAP messages and GTP messages as described in 
TS 48.018 [42], TS 25.413 [22], TS 29.060 [14] and TS 29.274 [43]. The MME performs relaying between SI and 
S3/Gn messages as described in TS 36.413 [36] and TS 29.274 [43] /TS 29.060 [14]. 

5.15.3 Applications using the RIM Procedures 

The RAN node applications, which use the RIM procedures, are fully transparent for the MME and SGSN. These 
applications are described in RAN specifications. An example between E-UTRAN and GERAN is the Network 
Assisted Cell Change described in TS 48.018 [42], TS 25.413 [22] and TS 36.413 [36]. An example between E- 
UTRAN and UTRAN is the exchange of SON related information described in TS 36.413 [36] 

5.16 MME-initiated procedure on UE's CSG membership change 

If the UE is in ECM-CONNECTED state and connected via a CSG cell and the MME detects that the UE's CSG 
membership to that cell has expired, the MME shall send an SlAP UE CONTEXT MODIFICATION REQUEST 
message to the eNodeB which includes an indication that the CSG membership of the UE has expired. The eNodeB 
receiving this indication may initiate a handover to another cell. If the UE is not handed over the eNodeB should initiate 
the SI release procedure with an appropriate cause. The MME initiates SI release after a configurable time if the UE is 
not handed over or released by the CSG cell. If the CSG membership expires for a UE with ongoing emergency bearer 
service, no indication that the CSG membership of the UE has expired is sent to the eNodeB and the MME shall 
deactivate all non-emergency PDN connections. 

If the UE is in ECM-CONNECTED state and connected via a hybrid cell and the MME detects that the UE's CSG 
membership to that cell has changed or expired, and the CSG Information Reporting Action indicates User CSG 
Information shall be reported to the P-GW then the MME shall modify the last known CSG membership and send a 
Change Notification message to the Serving GW with User CSG Information to indicate the CSG membership change. 
The Serving GW shall send the Change Notification message with the User CSG Information to the PDN GW. The 
MME shall also send the SlAP UE CONTEXT MODIFICATION REQUEST message to the eNodeB which includes 
an indication of whether the UE is a CSG member. Based on this information the eNodeB may perform differentiated 
treatment for CSG and non-CSG members. 
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5.17 Home eNodeB Multicast Packet Forwarding Function 

A Home eNodeB L-GW should receive and process multicast group membership report messages (e.g. according to 
RFC 3376 [62] / RFC 3810 [63]) sent either by the network accessed by LIPA or by the UE. Based upon these 
messages, the L-GW should forward multicast IP datagrams sent by the UE to the network accessed by LIPA, or from 
the network accessed by LIPA to the UE, as appropriate. 

The UE may implement RFC3376 [62] or RFC 3810 [63] to report multicast groups that the UE seeks to receive. 

To make UPnP/DLNA service advertisements sent with an IP TTL=1 available to UEs that employ LIPA, a proxying 
function in the L-GW may be implemented, e.g. to retransmit UPnP service advertisements to UEs after changing the 
source address. This proxying to the UE shall not be performed if the multicast packet is transmitted with an IPv4 or 
IPv6 Hnk-local source address, RFC 3927 [64], RFC 4291 [65]. 
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Annex A: 
Void 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 225 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 



Annex B: 
Void 
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Annex C: 
Void 
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Annex D (normative): 
Interoperation with Gn/Gp SGSNs 

D.1 General Considerations 

This annex specifies interworking between the EPS and 3GPP 2G and/or 3G SGSNs, which provide only Gn and Gp 
interfaces but no S3, S4 or S5/S8 interfaces, i.e. these Gn/Gp SGSNs provide no functionality that is introduced 
specifically for the EPS or for interoperation with the E-UTRAN. 

Interoperation scenarios for operating E-UTRAN with a PLMN maintaining Gn/Gp SGSNs are supported only with a 
GTP-based S5/S8. 

NOTE: PMIP-based S5/S8 may be used, but does not support handovers between the Gn/Gp SGSN and 
MME/S-GW. 

The S5/S8 interface for the Operator with Gn/Gp SGSNs will be GTP-based, but can be changed to PMIP-based S5/S8 
when the Gn/Gp SGSNs evolve to S4 SGSNs. 

For these interoperation scenarios the GERAN/UTRAN has to support interoperation with E-UTRAN. 



D.2 Interoperation Scenario 
D.2.1 Roaming interoperation scenario 

In the roaming scenario the vPLMN operates Gn/Gp 2G and/or 3G SGSNs as well as MME and S-GW for E-UTRAN 
access. The hPLMN operates a P-GW. 

Roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S-GW are enabled by: 
Gn functionality as specified between two Gn/Gp SGSNs, which is provided by the MME, and 
Gp functionality as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the P-GW. 

All this Gp and Gn functionality bases on GTP version 1 only. 

The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure D.2. 1-1. 
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Figure D.2.1 -1 : Roaming archiitecture for interoperation withi Gn/Gp SGSN 
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D.2.2 Non-roaming interoperation scenario 

In the non-roaming scenario the PLMN operates Gn/Gp 2G and/or 3G SGSNs as well as MME and S-GW for E- 
UTRAN access. 

Intra PLMN roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S-GW are enabled 

by: 

Gn functionality as specified between two Gn/Gp SGSNs, which is provided by the MME, and 

Gn functionality as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the P-GW. 

All this Gn functionality is based on GTP version 1 only. 

The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure D.2.2- 1. 





Operator's IP Servi^s 
He^. IMS, PSS ej 



Figure D.2.2-1 : Non-roaming Archiitecture for interoperation withi Gn/Gp SGSNs 

NOTE: If the Rel-7 SGSN applies Direct Tunnel there is a user plane connection between P-GW and UTRAN. 



D.3 Interoperation procedures 
D.3.1 General 

The interoperation procedures describe information flows for Gn/Gp SGSNs and other EPS network elements. All 
messages between Gn/Gp SGSN and MME, between Gn/Gp SGSN and HSS and between Gn/Gp SGSN and P-GW as 
well as the therein contained information elements are the same as specified for the adequate TS 23.060 [7] procedures 
that are between Gn/Gp SGSNs. These messages and procedure step descriptions are taken from TS 23.060 [7] for 
explanatory purposes only. These descriptions are in italic text and shall not be modified by the interoperation 
procedures. It cannot be assumed that the messages and procedure step descriptions that are taken from TS 23.060 [7] 
will be updated when modifications or corrections are performed for TS 23.060 [7]. If there are any discrepancies for 
these messages and procedure step descriptions TS 23.060 [7] takes precedence. The messages between the MME and 
any other node than the Gn/Gp SGSN as well as the therein contained information elements are the same as specified in 
the main body of this technical specification for the inter RAT Routing Area Update procedure. If there are any 
discrepancies for these messages the descriptions from the main body of this Technical Specification take precedence. 

An operator that has pre-Rel-8 SGSNs in its network should use separate EPS bearers for IPv4 and IPv6 addressing, 
such that both addresses can be maintained when moving to a pre-Rel-8 SGSN from a Rel-8 SGSN or MME (see 
clause 5.3.1). This is configured into the SGSN and MME nodes which set the Dual Address Bearer Flag depending on 
whether a UE may or may not be handed over to a pre-Rel-8 SGSN, as specified in clauses 5.3.2.1 and 5.10.2. 

An operator supporting emergency services shall not have pre-Rel-9 SGSNs in its network where a UE may be handed 
over. 
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D.3.2 Void 



D.3.3 MME to 3G SGSN combined hard handover and SRNS 
relocation procedure 

The MME to 3G Gn/Gp SGSN Combined Hard Handover and SRNS Relocation procedure is illustrated in 
Figure D.3.3-1. 

Any steps descriptions that are from inter Gn/Gp SGSNs procedures of TS 23.060 [7] are shown as italic text and 
remain unmodified. In those step descriptions an MS stands for UE, old SGSN for old MME and GGSN for P-GW. 

The procedure parts between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are compliant 
with the equivalent procedure parts in clause "5.5 Handover". 

If emergency bearer services are ongoing for the UE, handover to the target RNC is performed independent of the 
Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution phase, if the 
handover is to a restricted area and if so SGSN deactivate the non-emergency PDF context as specified in 
TS 23.060 [7], clause 9.2.4.2. 
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Figure D.3.3-1 : MME to 3G SGSN combined hiard hiandover and SRNS relocation procedure 

1. The source eNodeB decides to initiate a handover to the target access network, UTRAN lu mode. At this point 
both upHnk and downhnk user data is transmitted via the following: Bearer(s) between UE and source eNodeB, 
GTP tunnel(s) between source eNodeB, Serving GW and PDN GW. 

2. The source eNodeB sends a Handover Required (SlAP Cause, Target RNC Identifier, Source to Target 
Transparent Container) message to the source MME to request the CN to establish resources in the target RNC 
and the target SGSN. The bearers that will be subject to data forwarding (if any) are identified by the new SGSN 
in a later step (see step 5 below). 

3. The old MME sends a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM 
Context, PDF Context, Target Identification, RAN Transparent Container, RANAF Cause, GCSI) to the new 
SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used. 
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the old MME may have multiple new Gn/Gp SGSNs for each relocation target in a pool area, in which case the 
old MME will select one of them to become the new Gn/Gp SGSN, as specified in TS 23.236 [30]. PDP context 
contains GGSN Address for User Plane and UpUnk TEID for Data (to this GGSN Address and Uplink TEID for 
Data, the Serving GW and the new SGSN send uplink packets). At the same time a timer is started on the MM 
and PDP contexts in the old MME (see Routing Area Update procedure in clause "Location Management 
Procedures (lu mode)"). The old MME does not set any GCSI flag as the MME has no GPRS CAMEL 
Subscription Information. The SlAP Cause received from eNodeB is indicated as RANAP Cause. The Source to 
Target Transparent Container received from eNodeB is indicated as RAN Transparent Container. 

NOTE 1: The GGSN user plane address and uplink TEID are the old P-GW user plane address and TEID. The 
MME maps the EPS bearer parameters to PDP contexts. 

4. The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, 
Source RNC To Target RNC Transparent Container, RAB To Be Setup) to the target RNC. For each RAB 
requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters. 
Transport Layer Address, and lu Transport Association. SGSN shall not establish RABs for PDP contexts with 
maximum bitrate for uplink and downlink ofO kbit/s. The list of RABs requested by the new SGSN may differ 
from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent 
container. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC 
transparent container. Service Handover related information) that did not exist in the source RNC prior to the 
relocation. The RAB ID information element contains the NSAPI value, and the RAB parameters information 
element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the lu 
Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to 
establish Direct Tunnel unless it has received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to 
establish Direct Tunnel, it provides to the target RNC the GGSN's Address for User Plane and TEID for Uplink 
data. If the Access Restriction is present in the MM context, the Service Handover related information shall be 
included by the target SGSN for the Relocation Request message in order for RNC to restrict the UE in 
connected mode to handover to the RAT prohibited by the Access Restriction. 

After all the necessary resources for accepted RABs including the lu user plane are successfully allocated, the 
target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent 
Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup is defined by a 
Transport Layer Address, which is the target RNC Address for user data, and the lu Transport Association, 
which corresponds to the downlink Tunnel Endpoint Identifier for user data. The transparent container contains 
all radio-related information that the MS needs for the handover, i.e. a complete RRC message (e.g.. Physical 
Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN lu 
mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target 
RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN. 

NOTE 2: This step for the new SGSN is unmodified compared to pre-Rel-8. If the new SGSN decides to establish 
Direct Tunnel, it provides to the target RNC the P-GW Address for User Plane and TEID for Uplink data. 
The UE acts as the MS; the old eNodeB acts as the source SRNC. 

5. When resources for the transmission of user data between target RNC and new SGSN have been allocated and 
the new SGSN is ready for relocation ofSRNS, the Forward Relocation Response (Cause, RAN Transparent 
Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This 
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., 
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP 
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, 
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP 
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response 
message is applicable only in case of inter- SGSN SRNS relocation. 

NOTE 3: This step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and the source 
eNodeB as the source SRNC. 

6. If 'Indirect Forwarding' applies the source MME sends a Create Indirect Data Forwarding Tunnel Request 
message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane. Target 
RNC Address and TEID(s) for DL user plane) to the Serving GW. 

7. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL TEID(s)) 
message to the source MME. If the Serving GW doesn't support data forwarding, an appropriate cause value 
shall be returned. 
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8. The source MME completes the preparation phase towards source eNodeB by sending the message Handover 
Command (Target to Source Transparent Container, Bearers Subject to Data Forwarding List, SlAP Cause). 
"Bearers Subject to Data forwarding hst" may be included in the message and it shall be a list of 'Address(es) 
and TEID(s) for user traffic data forwarding' received from target side in the preparation phase (Step 5) in the 
case of direct forwarding or received from the Serving GW in the preparation phase (Step 7) in the case of 
indirect forwarding. RANAP Cause as received from new SGSN is indicated as SlAP Cause. RAN Transparent 
Container as received from new SGSN is indicated as Target to Source Transparent Container. 

9. The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided 
by source MME in the preparation phase. 

10. The source eNodeB will give a command to the UE to handover to the target access network via the message HO 
from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that 
the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are 
described in TS 36.300 [5]. 

11 Void. 

NOTE 4: The source eNodeB does not send any RAN contexts towards the target RNC. 

12. The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger 
is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the 
Uu interface; i.e., when target RNC detects the MS on the lower layers. When the Relocation Detect message is 
sent, the target RNC shall start SRNC operation. 

NOTE 5: This step is unmodified compared to pre-Rel-8. 

13. When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration 
Complete message to the target SRNC. 

The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer 
context activated after the ISR was activated in the UE exists. 

14. When the target SRNC receives the appropriate RRC message, e.g. Physical Channel Reconfiguration Complete 
message or the Radio Bearer Release Complete message in UTRAN case, or the Handover To UTRAN Complete 
message or Handover Complete message in GERAN case, i.e. the new SRNC-ID + S-RNTI are successfully 
exchanged with the MS by the radio protocols, the target SRNC shall initiate a Relocation Complete procedure 
by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete 
procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN 

NOTE 6: This step is unmodified compared to pre-Rel-8. The UE acts as the MS. 

15. Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the 
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall 
be released. 

NOTE 7: For the SGSN this step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and 
the source eNodeB as the source SRNC. 

16. Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to 
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established 
in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN 
Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, serving network identity, CGI/SAI, User CSG 
Information, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned. 
The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN 
provides to GGSN the RNC's Address for User Plane and TEID for Downlink data and shall include the DTI to 
instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. NRSN 
indicates SGSN support of the network requested bearer control. The GGSNs update their PDP context fields 
and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload 
Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM) 
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message. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDF context. 

The PDN GW shall include a Charging Id to be used at the SGSN as the Charging Id for reporting usage for this 
PDP context. The PDN GW shall include the Charging Id in the offline charging data. 

NOTE 8: This step is unmodified compared to pre-Rel-8. The P-GW acts as the GGSN. 

17. After the MS has finished the reconfiguration procedure and if the new Routing Area Identification is different 
from the old one or if the MS' TIN indicates "GUTI", the MS initiates the Routing Area Update procedure. See 
clause "Location Management Procedures (lu mode)". 

NOTE 9: It is only a subset of the RA update procedure that is performed, since the MS is in PMM -CONNECTED 

state. 

NOTE 10: This step is unmodified compared to pre-Rel-8. The UE acts as the MS. The old EPS bearer information 
in old MME and Serving GW is removed as part of the Routing Area Update procedure. 

18. When the timer started in step 15 expires, the source MME deletes the EPS bearer resources by sending Delete 
Session Request (Cause, Operation Indication) messages to the Serving GW because the new SGSN is a Gn/Gp 
SGSN, which is derived from using GTPvl for relocation signalling between new Gn/Gp SGSN and old MME. 
The new Gn/Gp SGSN does not signal any Serving GW change. The operation Indication flag is not set, that 
indicates to the Serving GW that the Serving GW shall not initiate a delete procedure towards the PDN GW. The 
Source Serving GW acknowledges with Delete Session Response (Cause) messages. If ISR is activated the cause 
indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old CN node by 
sending Delete Bearer Request message(s) to that CN node. If resources for indirect forwarding have been 
allocated then these are released. 

When the timer started in step 15 expires, the source MME sends a Release Resources message to the source 
eNodeB. When the Release Resources message has been received and there is no longer any need for the 
eNodeB to forward data, the source eNodeB releases its resources. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]) 

NOTE 1 l:The CI CAMEL procedure call was omitted intentionally from this procedure since EPS does not support 
CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8. 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context from the GGSN and then store the new Maximum APN restriction value. 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

If Routing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and 
initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data. 

If Routing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]): 

C2) CAMEL_GPRS_Routing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue ". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routing_Area_Update_Context. 
This procedure is called several times: once per PDP context. It returns as result "Continue". 
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow. 

NOTE 12:Handover Reject is performed as defined in clause 5.5.2.1.4, excluding steps 4 and 7. 
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D.3.4 3G SGSN to MME combined hard handover and SRNS 
relocation procedure 

The 3G Gn/Gp SGSN to MME Combined Hard Handover and SRNS Relocation procedure is illustrated in 
Figure D. 3. 4-1. 

Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step 
descriptions an MS stands for UE, new SGSN for new MME and GGSN for P-GW. 

The procedure between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are compliant with the 
equivalent procedure parts in clause 5.5: Handover. 

If emergency bearer services are ongoing for the UE, the MME checks as part of the Tracking Area Update in the 
execution phase, if the handover is to a restricted area and if so MME releases the non-emergency bearers as specified 
in clause 5.10.3. 
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Figure D.3.4-1 : 3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure 
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1 . The source RNC decides to initiate a handover to E-UTRAN. 

2. The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source 
RNC To Target RNC Transparent Container) to the old SGSN The source SRNC shall set Relocation Type to 
"UE Involved". Source RNC To Target RNC Transparent Container includes the necessary information for 
relocation co-ordination, security functionality and RRC protocol context information (including MS 
Capabilities). 

NOTE 1: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target RNC. 

NOTE la: The Target ID identifies an eNodeB. With Rel-8 lu functionahty this is an eNodeB ID. As an 

implementations option for supporting introduction scenarios with pre-Rel8 SGSNs the source RNC may 
be configured to use RNC IDs instead of eNodeB IDs to identify a target eNodeB. The Cause is relayed 
transparently by the SGSN to the MME and the MME mappes RANAP cause code to an SlAP cause 
code. Source RNC to Target RNC Transparent Container carries information for the target eNodeB. This 
container is relayed transparently by the SGSN. 

3. The old SGSN determines from the Target ID if the SRNS relocation is intra-SGSN SRNS relocation or inter- 
SGSN SRNS relocation. In case of inter-SGSN SRNS relocation the old SGSN initiates the relocation resource 
allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier 
Signalling, MM Context, PDF Context, Target Identification, RAN Transparent Container, RANAF Cause, 
GCSI) to the new SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple 
CN Nodes is used, the old SGSN may - if it provides Intra Domain Connection of RAN Nodes to Multiple CN 
Nodes -have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN will 
select one of them to become the new SGSN, as specified in TS 23.236 [30]. PDF context contains GGSN 
Address for User Flane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the old 
SGSN and the new SGSN send uplink packets). At the same time a timer is started on the MM and FDF contexts 
in the old SGSN (see Routing Area Update procedure in clause "Location Management Procedures (lu mode)"). 
The Forward Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. The old 
SGSN 'sets' the GCSI flag if the MM context contains GPRS CAMEL Subscription Information. 

NOTE 2: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the P-GW as 
the GGSN. The GGSN user plane address and uplink TEID are the P-GW user plane address and TEID. 
The MME maps the PDP context parameters to EPS bearers. 

4. The MME selects a Serving GW and sends a Create Session Request (bearer context(s) with PDN GW addresses 
and TEIDs for uplink traffic, APN-AMBR, Serving Network, UE Time Zone) message per PDN connection to 
the target Serving GW. For relocation from Gn/Gp SGSN, the target MME provides the APN-AMBR if not 
received explicitly from the Gn/Gp SGSN based on the mapping from MBR (as specified in Annex E) to the 
Serving GW. 

5. The Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one 
TEID per bearer). The target Serving GW sends a Create Session Response (Serving GW addresses and uplink 
TEID(s) for user plane) message back to the target MME. 

6. The new MME requests the target eNodeB to establish the bearer(s) by sending the message Handover Request 
(UE Identifier, SlAP Cause, CN Domain Indicator, KeNB, NAS Security Parameters to E-UTRAN, EPS Bearers 
to be setup list. Source to Target Transparent Container, Serving GW Address(es) and TEID(s) for User Traffic 
Data, Handover Restriction List). SlAP Cause indicates the RANAP Cause as received from SGSN. Source to 
Target Transparent Container contains the RAN Transparent Container as received from SGSN. The NAS 
Security Parameters to E-UTRAN includes the NAS Integrity Protection and Ciphering algorithm(s), eKSI and 
NONCEmme information elements. Handover Restriction List is sent if it is available in the Target MME; it is 
described in clause 4.3.5.7. 

If the MME did not receive the UE Network Capabihty information from the old SGSN, then the MME will not 
have received information on the E-UTRAN Integrity Protection and Encryption algorithms that the UE 
supports. In this case, the MME can assume that the UE supports both EIAl/EEAl and EIA2/EEA2. 

NOTE 3: The MME derives K'asme from CK and IK in the MM context and associates it with eKSI, as described in 
TS 33.401 [41] and selects NAS Integrity Protection and Ciphering algorithms(s). eKSI and key 
derivation parameters are targeted for UE. The MME and UE derive the NAS keys and Ksnb from K'asme- 
If the MME shares an EPS security association with the UE, the MME may activate this native EPS 
security context by initiating a NAS SMC procedure after having completed the handover procedure. 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 236 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

The MME shall not request the target eNodeB to establish EPS GBR bearers with maximum bitrate set to and 
those EPS bearers should not be included in the EPS Bearers to be setup list and should be deactivated by the 
MME. For the remaining EPS Bearer Contexts the MME ignores any Activity Status Indicator within an EPS 
Bearer Context and requests the target eNodeB to allocate resources for all the remaining EPS Bearer Contexts. 

The MME shall compute the UE-AMBR, according to clause 4.7.3, based on explicit APN-AMBR values 
received from the Gn/Gp SGSN. If explicit APN-AMBR values are not received by the MME, a local UE- 
AMBR shall be included in the 'EPS Bearers be setup list ' IE. The local UE-AMBR is described in clause 
Annex E. 

"Data forwarding not possible" indication per bearer shall be included in the 'EPS Bearers to be setup list' if the 
target MME decides the corresponding bearer will not be subject to data forwarding. 

NOTE 4: The MME derives the security parameters from the security parameters received from the SGSN. 

NOTE 5: An MME that supports handovers from pre-Rel-8 3G SGSNs derives from the RNC ID received from old 
SGSN an eNodeB address. 

7. The target eNodeB allocates the requested resources and returns the applicable parameters to the target MME in 
the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list, 
EPS Bearers failed to setup list. Cause). The target eNodeB shall ignore it if the number of radio bearers in the 
Source to Target Transparent container does not comply with the number of bearers requested by the MME and 
allocate bearers as requested by the MME. 

The target eNodeB inserts the information provided by the MME (KSI, selected NAS Integrity Protection and 
Ciphering algorithm(s), NONCEmme) and selected AS integrity and ciphering algorithm(s) into the UTRAN 
RRC message, which is contained in the Target to Source Transparent Container. 

8. If 'Indirect Forwarding' and relocation of Serving GW apply the target MME sends a Create Indirect Data 
Forwarding Tunnel Request message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address 
for Control plane. Target eNodeB Address and TEID(s) for DL user plane) to the Serving GW. The allocation of 
a new Serving GW by steps 4 and 5 the MME shall consider as a Serving GW change. 

9. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL TEID(s)) 
message to the source MME. If the Serving GW doesn't support data forwarding, an appropriate cause value 
shall be returned. 

10. When resources for the transmission of user data between target RNC and new SGSN have been allocated and 
the new SGSN is ready for relocation ofSRNS, the Forward Relocation Response (Cause, RAN Transparent 
Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This 
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., 
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP 
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, 
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP 
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response 
message is applicable only in case of inter- SGSN SRNS relocation. 

NOTE 6: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the target 

eNodeB as the target SRNC. RANAP Cause indicates the Cause as received from target eNodeB. RAN 
Transparent Container contains the Target to Source Transparent Container as received from eNodeB. 

11. The old SGSN continues the relocation of SRNS by sending a Relocation Command message (Target RNC To 
Source RNC Transparent Container, RABs To Be Released, RABs Subject To Data Forwarding) to the source 
SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall be 
contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information 
element shall contain RAB ID, Transport Layer Address, and lu Transport Association. These are the same 
Transport Layer Address and lu Transport Association that the target RNC had sent to new SGSN in Relocation 
Request Acknowledge message, and these are used for forwarding of downlink N-PDU from the source SRNC to 
the target RNC. The source SRNC is now ready to forward downlink user data directly to the target RNC over 
the lu interface. This forwarding is performed for downlink user data only. 

NOTE 7: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target RNC, and the new 
MME acts as the new SGSN. The forwarding of downlink user data from source SRNC may go directly 
to target eNodeB or via the Serving GW. 
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12. The source SRNC may, according to the QoS profile, begins the forwarding of data for the RABs to be subject 
for data forwarding. 

NOTE 8: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For 
instance, source RNC may start data forwarding (step 7), send the RRC message to MS (step 8) and 
forward SRNS Context message to the old SGSN (step 9) almost simultaneously. 

The data forwarding at SRNS relocation shall be carried out through the lu interface, meaning that the GTP- 
PDUs exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed 
at the IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related 
to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target 
RNC together with their related downlink PDCP sequence numbers. The source RNC continues transmitting 
duplicates of downlink data and receiving uplink data. 

Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to 
arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the 
related QoS profile. 

NOTE 9: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target SRNC. The data 

forwarding may go directly to target eNodeB or alternatively go via the Serving GW if so decided by new 
MME in the preparation phase. 

13. Before sending the RRC message the uplink and downlink data transfer shall be suspended in the source SRNC 
for RABs, which require delivery order. The RRC message is for example Physical Channel Reconfiguration for 
RNS to RNS relocation, or Intersystem to UTRAN Handover for BSS to RNS relocation, or Handover from 
UTRAN Command for BSS relocation, or Handover Command for BSS to BSS relocation. When the source 
SRNC is ready, the source RNC shall trigger the execution of relocation of SRNS by sending to the MS the RRC 
message provided in the Target RNC to source RNC transparent container, e.g., a Physical Channel 
Reconfiguration (UE Information Elements, CN Information Elements) message. UE Information Elements 
include among others new SRNC identity and S-RNTI. CN Information Elements contain among others Location 
Area Identification and Routing Area Identification. 

When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration 
Complete message to the target SRNC. If the Forward SRNS Context message with the sequence numbers is 
received, the exchange of packets with the MS may start. If this message is not yet received, the target RNC may 
start the packet transfer for all RABs, which do not require maintaining the delivery order. 

NOTE 10: This step is unmodified compared to pre-Rel-8. This text is valid for the RRC message sent from source 
RNC to the UE. When the UE has got access to target eNodeB it sends the HO to E-UTRAN Complete 
message. This RRC message received as part of Target to Source Transparent Container, includes 
information about the selected security algorithms and related key information. Based on this information, 
the UE selects the same algorithms for the NAS if the KSI value indicates that the MME has no security 
association with the UE. If the KSI value indicates that the MME has a security association with the UE, 
but the UE has lost the security context of the E-UTRAN side (error case), the UE will start Attach 
procedure on the E-UTRAN side 

14. There is no RAN context transfer during inter RAT handovers with E-UTRAN. If the source RNC originates any 
SRNC contexts the MME acknowledges the receipt towards the SGSN and ignores the message content. 

NOTE ll:This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the target 
eNodeB as the target SRNC. 

15. When the UE has successfully accessed the target eNodeB, the target eNodeB informs the target MME by 
sending the message Handover Notify (TAIh-ECGI). The UE shall implicitly derive the EPS bearers for which an 
E-RAB was not established from the HO from UTRAN Command and deactivate them locally without an 
explicit NAS message at this step. 

16. Upon receipt of Handover Notify message, if the SRNS Relocation is an inter SGSN SRNS relocation, the new 
SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

Upon receipt of the Relocation Complete message the new MME starts a timer. 
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NOTE 12:This step is unmodified compared to pre-Rel-8 except that the Handover Notify message is received 
instead of a Relocation Complete message. The new MME acts as the new SGSN. 

17. The target MME will now complete the handover procedure by informing the Serving GW that the target MME 
is now responsible for all the bearers the UE have established. This is performed in the message Modify Bearer 
Request (Cause, Tunnel Endpoint Identifier Control Plane, MME Address for Control Plane, eNodeB 
Address(es) and TEID(s) for User Traffic, RAT type, APN-AMBR) per PDN connection. If the PDN GW 
requested UE's location information and/or User CSG information (determined from the UE context), the MME 
also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time 
Zone has changed, the MME includes the UE Time Zone IE in this message. 

The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in 

clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL 

packet and does not send a Downlink Data Notification to the MME. 

18. The Serving GW informs the PDN GW the APN-AMBR and the change of for example the RAT type that e.g. 
can be used for charging, by sending the message Modify Bearer Request (APN-AMBR, Serving Network) per 
PDN connection. The S-GW also includes User Location Information IE and/or UE Time Zone IE and/or User 
CSG Information IE if it is present in step 17. The Serving GW allocates DL TEIDs on S5/S8 even for non- 
accepted bearers. The PDN GW must acknowledge the request with the message Modify Bearer Response 
(Default bearer id, APN Restriction). When the UE moves from Gn/Gp SGSN to the MME, the PDN GW shall 
send the APN restriction of each bearer context to the Serving GW. 

19. The Serving GW acknowledges the user plane switch to the target MME via the message Modify Bearer 
Response (Cause, Tunnel Endpoint Identifier Control Plane, Serving GW Address for Control Plane, Default 
bearer id, APN restriction). The Serving GW shall forward the received APN Restriction to the MME. At this 
stage the user plane path is established for all bearers between the UE, target eNodeB, Serving GW and PDN 
GW. 

20. Upon receiving the Relocation Complete message or, if it is an inter-SGSN SRNS relocation, the Forward 
Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC When 
the RNC data-forwarding timer has expired, the source RNC responds with an lu Release Complete message. 

NOTE 13:This step is unmodified compared to pre-Rel-8. 

21. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for 
tracking area update" applies. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. The 
target MME gets the subscribed UE-AMBR value and the subscribed APN-AMBR value from the HSS during 
the TA update procedure. 

22. The target MME calculates UE-AMBR as defined in clause 4.7.3. If this calculated value is different from the 
UE-AMBR computed during step 6, or the APN-AMBR mapped from the subscribed MBR is different from the 
subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. the subscribed QoS profile mapped 
according to Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the 
HSS, the new MME shall initiate Subscribed QoS Modification procedure as described in clause 5.4.2.2, Figure 
5.4.2.2-1. 

23. When the timer started in step 16 expires the new MME releases the resources that have been allocated for 
indirect forwarding. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]) 

CI) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 
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Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDF 
context from the GGSN and then store the new Maximum APN restriction value. 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

If Routing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and 
initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data. 

If Routing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]): 

NOTE 14: This CAMEL handling is unmodified compared to pre-Rel-8. 

NOTE 15: CAMEL procedure calls C2 and C3 were omitted intentionally from this procedure since EPS does not 
support CAMEL procedure calls. 

NOTE 16:Handover Reject procedure is performed as defined in clause 5.5.2.2.4. 



D.3.5 Routing Area Update 



The Routing Area Update procedure takes place when a UE that is registered with an MME selects a UTRAN or 
GERAN cell served by a Gn/Gp SGSN. In this case, the UE changes to a Routing Area that the UE has not yet 
registered with the network. This procedure is initiated by an idle state or by a connected state UE. The Routing Area 
Update procedure is illustrated in Figure D.3.5- 1. 

Any step descriptions that are taken from TS 23.060 [7] for a Gn/Gp SGSN are shown as italic text and remain 
unmodified. In that step descriptions an MS stands for UE, old SGSN for old MME and GGSN for P-GW. The old 
MME behaves towards the new Gn/Gp SGSN always like an old Gn/Gp 3G-SGSN, regardless of whether the new 
Gn/Gp SGSN is a 2G-SGSN or a 3G-SGSN. 
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Figure D.3.5-1 : Routing Area Update procedure 

0. The UE selects a UTRAN or GERAN cell. This cell is in a Routing Area that the UE not yet registered with the 
network or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in 
ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell Change (NACC). 

1. The MS sends a Routing Area Update Request (old P-TMSI, old RAI, old P-TMSI Signature, Update Type, 
follow on request, Classmark, MS Network Capability, additional P-TMSI/RAI, KSI) to the new SGSN. Update 
Type shall indicate RA update, periodic RA update. Combined RA / LA Update or Combined RA / LA Update 
with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell 
where the message was received before passing the message to the SGSN. The SRNC shall add the Routing Area 
Identity before forwarding the message to the 3G-SGSN. Classmark contains the MS GPRS multislot 
capabilities and supported GPRS ciphering algorithms as defined in TS 24.008 [47]. The SGSN may use, as an 
implementation option, the follow-on request indication to release or keep the lu connection after the completion 
of the RA update procedure. 

If the UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the old 
P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid 
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to 
a P-TMSI and an RAI is specified in TS 23.003 [9]. 
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If the UE holds a valid P-TMSI and related RAI and the old P-TMSI and old RAI indicate a P-TMSI/RAI 
mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI. The Gn/Gp SGSN 
shall ignore this additional P-TMSI/RAI. 

The old P-TMSI is indicated in the RAU Request message for lu-mode only. For Gb mode the TLLI is derived 
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is 
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is 
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to 
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) 
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 

KSI is mapped from an eKSI indentifying a Kasme if the UE indicates a P-TMSI mapped from GUTI in the 
information element "old P-TMSI". KSI identifies a (CK, IK) pair if the UE indicates a P-TMSI in the 
information element "old P-TMSI". 

2. The new SGSN sends SGSN Context Request (old RAI, TLLI or old P-TMSI, old P-TMSI Signature, New SGSN 
Address) to the old SGSN to get the MM and PDP contexts for the MS. If the new SGSN provides functionality 
for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from 
the old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this old SGSN. 
Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an 
SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same 
pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) and 
relay the message to that actual old SGSN. 

NOTE 2: A GUTI mapped to a P-TMSI/RAI provides an old RAI that uniquely identifies an old MME then there is 
no need to relay between MME in the old pool, regardless whether the new SGSN supports such 
functionality or not. Mapping a GUTI to a P-TMSI and an RAI is specified in Annex H. 

The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not 
match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the 
security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI, 
TLLI, MS Validated, New SGSN Address) message to the old SGSN. MS Validated indicates that the new SGSN 
has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has 
authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old SGSN 
responds with an appropriate error cause. 

If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated 
UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it 
cannot validate the Context Request. 

NOTE 3: For the new SGSN, this step is unmodified compared to pre-Rel-8. The MME (called old SGSN in above 
description) needs to provide SGSN functionality. 

2b. The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each 
PDP context the old 3G-SGSN shall include the GTP sequence number for the next uplink GTP PDU to be 
tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to be sent to the MS. Each 
PDP Context also includes the PDCP sequence numbers ifPDCP sequence numbers are received from the old 
SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context 
Response only when it has previously received an MS Network Capability in the Routing Area Request. The GTP 
sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for the PDP 
context (QoS profile). 

NOTE 4: This step is for the Gn/Gp SGSN unmodified compared to pre-Rel-8. The MME (old SGSN in this step) 
maps EPS bearers one-to-one to PDP contexts and provides the Release 99 parameters of the bearer QoS 
profile to the new SGSN. The Gn signalling between the new Gn/Gp SGSN and the old CN node has no 
capabilities to indicate ISR Activated or ISR Supported. The GTP and PDCP sequence numbers are not 
relevant as the network does not configure usage of "delivery order required" and does not configure loss 
less UTRAN PDCP as described in clause "compatibility issues". 

3. Security functions may be executed. These procedures are defined in clause "Security Function" in 

TS 23.060 [7]. Ciphering mode shall be set if ciphering is supported. If the SGSN Context Response message did 
not include IMEISV and ADD is supported by the SGSN, the SGSN retrieves the IMEISV from the MS. 
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If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send 
Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS 
with an appropriate cause. 

NOTE 5: This step is unmodified compared to pre-Rel-8. 

4. The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old MME (which is the old 
SGSN from the new SGSN's point of view) marks in its context that the information in the GWs and the HSS are 
invalid. This triggers the GWs, and the HSS to be updated if the UE initiates a Tracking Area Update procedure 
back to the old MME before completing the ongoing Routing Area Update procedure. If the security functions do 
not authenticate the MS correctly, then the routing area update shall be rejected, and the new SGSN shall send a 
reject indication to the old SGSN. The old MME shall continue as if the SGSN Context Request was never 
received. 

NOTE 6: The new SGSN's operation is unmodified compared to pre-Rel-8. The old MME/S-GW (old SGSN from 
the new SGSN's point of view) does not forward any data towards the new SGSN. 

5. Void. 

6. The new SGSN sends Update PDF Context Request (new SGSN Address, TEID, QoS Negotiated, serving 
network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, 
NRSN) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN NRSN 
indicates SGSN support of the network requested bearer control. The SGSN shall only indicate that it supports 
the procedure if it supports it and it is indicated that the MS also supports it in the SGSN Context Response 
message as described above. If the NRSN is not included in the Update PDF Context Request message the GGSN 
shall, following this procedure, perform a GGSN -Initiated PDP Context Modification to change the BCM to 
'MS-Only' for all PDP-Address/APN-pairs for which the current BCM is 'MS/NW. The GGSNs update their 
PDP context fields and return Update PDP Context Response (TEID, Prohibit Payload Compression, APN 
Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM). The Prohibit Payload 
Compression indicates that the SGSN should negotiate no data compression for this PDP context. 



NOTE 9: This step is unmodified compared to pre-Rel-8. 



7. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI, IMEISV, Update Type, Homogenous Support of IMS Over PS Sessions) to the HLR. IMEISV is 
sent if the ADD function is supported. Update Type indicates "normal update". Homogenous Support of IMS 
Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all 
RAs in the serving SGSN. 

NOTE 10:This step is unmodified compared to pre-Rel-8. Clarification about update type added to show that this is 
the trigger for the HSS to cancel only an old SGSN and not also an old MME. 

8. The HLR sends Cancel Location (IMSI, Cancellation Type) to any old SGSN with Cancellation Type set to 
Update Procedure. The old SGSN removes the MM and EPS bearer contexts. The old SGSN acknowledges with 
Cancel Location Ack (IMSI). 

NOTE 11: For the Gn/Gp SGSN the HSS interoperation is unmodified compared to earlier standards Releases. 

9. The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The new SGSN 
validates the UE's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the 
MS is not allowed to be attached in the RA, the SGSN rejects the Routing Area Update Request with an 
appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the 
HLR. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 
Network Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to 
the RNS, as described in TS 23.251 [24] instead of rejecting the Routing Area Update Request. If all checks are 
successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) 
message to the HLR. 

NOTE 12:This step is unmodified compared to pre-Rel-8. 

10. The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN. 
NOTE 13: This step is unmodified compared to pre-Rel-8. 
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1 1 . If the new SGSN is a 2G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming 
restrictions or access restrictions the MS, is not allowed to be attached in the SGSN, or if subscription checking 
fails, the new SGSN rejects the routing area update with an appropriate cause. If all checks are successful, the 
new SGSN constructs MM and PDF contexts for the MS. A logical link is established between the new SGSN and 
the MS. The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI, P-TMSI Signature, 
Receive N-PDU Number). Receive N-PDU Number contains the acknowledgements for each acknowledged- 
mode NSAPI used by the MS, thereby confirming all mobile-originated N-PDUs successfully transferred before 
the start of the update procedure. 

If the new SGSN is a 3G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming 
restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking 

fails, the SGSN rejects the routing area update with an appropriate cause. If the network supports the MOCN 
configuration for network sharing, the SGSN may, if the MS is not a Network Sharing Supporting MS', in this 
case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [24] 
instead of rejecting the routing area update. If all checks are successful, the new SGSN establishes MM context 

for the MS. The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI VLR TMSI P-TMSI 
Signature). 

For a MS with ongoing emergency bearer services, the new 3G-SGSN accepts the Routing Area Update Request 
and deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 in TS 23.060 [7]. 

When receiving the RAU Accept message and there is no ISR Activated indication the UE shall set its TIN to 
"P-TMSI". 

NOTE 13a: A Gn/Gp SGSN never indicates ISR Activated as it does not support ISR. 

NOTE 14: For the SGSN this step is unmodified compared earlier standards Releases. N-PDU numbers are not 

relevant as the network does not configure usage of acknowledged mode NSAPIs as described in clause 
"compatibility issues". 

12. If the new SGSN is a 2G-SGSN: The MS acknowledges the new P-TMSI by returning a Routing Area Update 
Complete (Receive N-PDU Number) message to the SGSN. Receive N-PDU Number contains the 
acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile- 
terminated N-PDUs successfully transferred before the start of the update procedure. If Receive N-PDU Number 
confirms reception of N-PDUs that were forwarded from the old SGSN, these N-PDUs shall be discarded by the 
new SGSN. LLC and SNDCP in the MS are reset. 

If the new SGSN is a 3G-SGSN: The MS confirms the reallocation of the TMSIs by returning a Routing Area 
Update Complete message to the SGSN. 

NOTE 15: This step is unmodified compared to pre-Rel-8. N-PDU numbers are not relevant as the network does not 
configure usage of acknowledged mode NSAPIs as described in clause "compatibility issues". 

13. When the timer started in step 2) expires the old MME releases any RAN and Serving GW resources. The old 
MME deletes the EPS bearer resources by sending Delete Session Request (Cause; Operation Indication) 
messages to the Serving GW. The operation Indication flag is not set, that indicates to the old Serving GW that 
the old Serving GW shall not initiate a delete procedure towards the PDN GW. The old MME derives from the 
GTPvl context transfer signalling that the new SGSN is a Gn/Gp SGSN and therefore any old S-GW resources 
are released by the old MME. A Gn/Gp SGSN does not signal any S-GW change. If the old S-GW has due to 
ISR a control connection with another CN node (MME or SGSN) the cause indicates to the old S-GW that the 
old S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request 
message(s) to that other old CN node. 

If the old MME has an SI -MME association for the UE, the source MME sends a Sl-U Release Command to the 
source eNodeB when receiving the SGSN Context Acknowledge message from the new SGSN. The RRC 
connection is released by the source eNodeB. The source eNodeB confirms the release of the RRC connection 
and of the Sl-U connection by sending a S 1 -U Release Complete message to the source MME. 

NOTE 16:The new SGSN may initiate RAB establishment after execution of the security functions, or wait until 
completion of the RA update procedure. For the MS, RAB establishment may occur anytime after the 
Routing Area Update Request is sent. 

In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions, access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) or because the SGSN cannot determine the HLR address to 
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establish the locating updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to 
the MS with an appropriate cause and the PS signalling connection shall be released. Upon return to idle, the MS shall 
act according to TS 23.122 [10]. 

If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 'Network 
Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as 
described in TS 23.251 [24] instead of rejecting the routing area update. 

If the new SGSN is unable to update the PDF context in one or more GGSNs, the new SGSN shall deactivate the 
corresponding PDF contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall 
not cause the SGSN to reject the routing area update. 

The PDP Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context first 
in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based 
on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context from the GGSN and then store the new Maximum APN restriction value. 

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new 
SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts to maintain active 
and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more GGSNs and then 
deactivate the context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context Deactivation 
Procedure". This shall not cause the SGSN to reject the routing area update. 

NOTE 17: In case MS was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward 
Relocation Request message as described in clause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing 
Area Update Reject (Cause) message, the MS shall enter IDLE state. 

NOTE 18: The CI CAMEL procedure call was omitted intentionally from this procedure since EPS does not support 
CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [29]: 

C2) CAMEL_GPRS_Routing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue ". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routing_Area_Update_Context. 

D.3.6 Gn/Gp SGSN to MME Tracking Area Update 

The Pre-Rel-8 SGSN to MME Tracking Area Update procedure is illustrated in Figure D.3.6-1. 

Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step 
descriptions an MS stands for UE, new SGSN for new MME, old SGSN for old Gn/Gp SGSN, GGSN for P-GW, and 
HLR for HSS. The new MME behaves towards the old Gn/Gp SGSN always like a Gn/Gp 3G-SGSN, regardless of 
whether the old Gn/Gp SGSN is a 2G-SGSN or a 3G-SGSN. 
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Figure D.3.6-1 : Gn/Gp SGSN to MME Tracking Area Update procedure 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 13 and 15 concern GTP 
based S5/S8. 

1 . One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs. 

2. The UE sends to the eNodeB a Tracking Area Update Request (last visited TAl, P-TMSl Signature, old GUTl, 
UE Core Network Capability, active flag, EPS bearer status, additional GUTl, eKSl, NAS sequence number, 
NAS-MAC, KSl) message together with RRC parameters indicating the Selected Network and the old 
GUMMEl. 

If the UE's TIN indicates "GUTl" or "RAT-related TMSl" and the UE holds a valid GUTl then the old GUTl 
indicates this valid GUTl. If the UE's TIN indicates "P-TMSl" and the UE holds a vaUd P-TMSl and related RAI 
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then these two elements are indicated as the old GUTI. Mapping a P-TMSI and an RAI to a GUTI is specified in 
Annex H. 

If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE 
indicates the native GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and the UE has a 
valid P-TMSI signature, the P-TMSI signature shall be included. 

The RRC parameter "old GUMMEI" takes its value from the identifier that is signalled as the old GUTI 
according to the rules above. For a combined MME/SGSN the eNodeB is configured to route the MME-code(s) 
of this combined node to the same combined node. This eNodeB is also configured to route MME-code(s) of 
GUTIs that are generated by the UE's mapping of the P-TMSIs allocated by the combined node. Such an 
eNodeB configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter 
RAT mobility. 

NOTE 2: In the scenario of this flow the UE's TIN indicates "P-TMSI" and therefore the UE indicates a P-TMSI as 
the old GUTI. 

The last visited TAI is included if the UE has any in order to help the MME to produce a good list of TAIs for 
any subsequent TAU Accept message. Selected Network indicates the network that is selected. Active flag is a 
request by UE to activate the radio and S 1 bearers for all the active EPS Bearers by the TAU procedure. The 
EPS bearer status indicates each EPS bearer that is active within the UE. The UE's ISR capability is included in 
the UE Core Network Capability element. 

If the UE has valid EPS security parameters, the TAU Request message shall be integrity protected by the 
NAS-MAC in order to allow validation of the UE by the MME. eKSI, NAS sequence number and NAS-MAC 
are included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number 
of the NAS message. KSI is included if the UE indicates a GUTI mapped from a P-TMSI in the information 
element "old GUTI". 

3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected 
Network. If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available, the eNodeB 
selects the MME as described in clause 4.3.8.3 on "MME Selection Function". 

The eNodeB forwards the TAU Request message together with the TAIh-ECGI of the cell from where it received 
the message and with the Selected Network to the MME. 

4. The new MME sends SGSN Context Request (old RAI, P-TMSI, old P-TMSI Signature, New SGSN Address) 
to the old SGSN to get the MM and PDP contexts for the UE. 

The new MME shall support functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, 
i.e. the MME derives the old SGSN from the old RAI and the old P-TMSI (or TLLI). 

5. If the old SGSN is a 2G-SGSN: The old 2G-SGSN validates the old P-TMSI Signature and responds with an 
appropriate error cause if it does not match the value stored in the old 2G SGSN. This should initiate the 
security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall 
send an SGSN Context Request (old RAI, old PTMSI, MS Validated, New SGSN Address) message to the old 
SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was 
valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP 
N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP 
Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The 
old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN. Each 
PDP Context includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in 
acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink N-PDU to be received in 
acknowledged mode from the MS, the GTP sequence number for the next downlink N-PDU to be sent to the MS 
and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. The old SGSN starts a 
timer and stops the transmission of N-PDUs to the MS. The new SGSN shall ignore the MS Network Capability 
contained in MM Context of SGSN Context Response only when it has previously received an MS Network 
Capability in the Routing Area Request. 

If the old SGSN is a 3G-SGSN; The old 3G-SGSN validates the old P-TMSI Signature and responds with an 
appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security 
functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an 
SGSN Context Request (IMSI, old RAI, MS Validated) message to the old 3G-SGSN. MS Validated indicates that 
the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates 
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that it has authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old 
3G-SGSN responds with an appropriate error cause. 

If the UE with emergency bearers is not authenticated in the old MM E (in a network supporting unauthenticated 
UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it 
cannot validate the Context Request. 

The old 3G SGSN responds with an SGSN Context Response (MM Context, PDF Contexts) message. For each 
FDF context the old 3G SGSN shall include the GTF sequence number for the next uplink GTF FDU to be 
tunnelled to the GGSN and the next downlink GTF sequence number for the next FDU to be sent to the MS. Each 
FDF Context also includes the FDCF sequence numbers ifFDCF sequence numbers are received from the old 
SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context 
Response only when it has previously received an MS Network Capability in the Routing Area Request. The GTF 
sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for the FDF 
context (QoS profile). 

NOTE 3: In this step, the new "SGSN" shall be understood to be a new "MME" and the old SGSN stores new 

SGSN Address, to allow the old SGSN to forward data packets to the new "S-GW or eNodeB". This step 
describes both the 2G and 3G SGSN variants due to combining the 2G or 3G SGSN to MME TAU into a 
single procedure. 

NOTE 4: For the old SGSN, this step is unmodified compared to pre-Rel-8. The MME (called new SGSN in above 
description) must provide SGSN functionality which includes mapping PDP contexts to EPS bearer 
information. SNDCP, GTP and PDCP sequence numbers are not relevant for the MME as the network 
does not configure usage of "delivery order required", does not configure acknowledged mode NS APIs 
(SNDCP) and does not configure loss less UTRAN PDCP as described in clause "compatibility issues". 

6. Security functions may be executed. Procedures are defined in clause 5.3. 10 on Security Function. If the SGSN 
Context Response message from the old SGSN did not include IMEISV, the MME shall retrieve the ME Identity 
(the IMEISV) from the UE. 

7. The new MME sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSN that 
the new SGSN is ready to receive data packets belonging to the activated FDF contexts. The old SGSN marks in 
its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This 
triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a Routing area update 
procedure back to the old SGSN before completing the ongoing routing area update procedure. 

If the security functions do not authenticate the UE correctly, then the Tracking area update shall be rejected, and 
the new MME shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN 
Context Request was never received. 

NOTE 5: in the italic text of this step, new "SGSN" shall be understood as to be a new "MME". The MME needs to 
map PDP contexts received from pre-Rel-8 SGSN into EPS bearer information. The GGSN address(es) 
and TEIDs map to the PDN GW address(es) and TEIDs respectively. . The MME maps PDP contexts to 
EPS bearers one-to-one and it translates the release 99 QoS parameters to the EPS bearer QoS parameters. 

NOTE 6: The SGSN operation is unmodified compared to pre-Rel-8. The MME indicates reserved TEID and IP 
address parameters from an S-GW to the old SGSN so that the old Gn/Gp SGSN can forward data 
packets when needed. The S-GW discards any packets received from old Gn/Gp SGSN. 

NOTE 7: The Gn signalling between the new MME and the old Gn/Gp SGSN has no capabilities to indicate ISR 
Supported or ISR Activated. 

If there is no PDP context at all, the MME rejects the TAU Request. 

8. The old SGSN or the old RNC forward data to the S-GW and the S-GW discards these data. 

9. The new MME adopts the bearer contexts received from the SGSN as the UE's EPS bearer contexts to be 
maintained by the new MME. The new MME maps the PDP contexts to the EPS bearers I -to- 1 and maps the 
Release 99 QoS parameter values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer as 
defined in Annex E. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the 
EPS bearers which cannot be established. 
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The MME verifies the EPS bearer status received fi-om the UE with the bearer contexts received fi-om the old 
SGSN and releases any network resources related to EPS bearers that are not active in the UE. If the UE has no 
PDP context, the MME rejects the TAU Request. 

The new MME selects a Serving GW and sends an Create Session Request (IMSI, MME Address and TEID, 
PDN GW address and TEID, EPS Bearer QoS, serving network identity, ME Identity, User Location 
Information IE, UE Time Zone IE, User CSG Information IE, RAT type, MS Info Change Reporting support 
indication, NRS (received from the SGSN)) message per PDN connection to the Serving GW. The MME shall 
send the serving network identity to the Serving GW. The new MME does not indicate ISR Activated. 

10. The Serving GW creates contexts and informs the PDN GW(s) about the change of the RAT type. The Serving 
GW sends a Modify Bearer Request (Serving GW Address and TEID, RAT type, ME Identity, User Location 
Information IE, UE Time Zone IE, User CSG Information IE, MS Info Change Reporting support indication) 
message per PDN connection to the PDN GW(s) concerned. 

11 . If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF, 
then the PDN GW shall send RAT type information to the PCRF by performing an IP -CAN Session 
Modification procedure as defined in TS 23.203 [6]. 

NOTE 8: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

12. The PDN GW updates its context field and returns a Modify Bearer Response (PDN GW address and TEID, 
MSISDN, Default bearer id. Charging Id, MS Info Change Reporting Action (Start) (if the PDN GW decides to 
receive UE's location information during the session), CSG Information Reporting Action (Start) (if the PDN 
GW decides to receive UE's User CSG information during the session), APN Restriction) message to the Serving 
GW. The MSISDN is included if the PDN GW has it stored in its UE context. When the UE moves from Gn/Gp 
SGSN to the MME, the PDN GW shall send the APN restriction of each bearer context to the Serving GW. 

13. The Serving GW updates its context and returns an Create Session Response (Serving GW address and TEID for 
user plane, PDN GW address and TEID, Serving GW Address and TEID for the control plane. Default bearer id, 
APN restriction) message to the new MME. The message also includes MS Info Change Reporting Action 
(Start) and/or CSG Information Reporting Action (Start) if they are included in step 12. The Serving GW shall 
forward the received APN Restriction to the MME. 

14. To ensure the release of all UE resources in the Gn/Gp SGSN the new MME informs the HSS of the change of 
the serving core network node by sending an Update Location Request (MME Address, IMSI, ME Identity, 
ULR-Flags, MME Capabilities, Homogenous Support of IMS Over PS Sessions) message to the HSS. The ME 
Identity is included if the SGSN Context Response did not contain the IMEISV. Because of interoperation with 
an Gn/Gp SGSN, which the new MME identifies from the GTPvl Context Response signalling, the ULR-Flags 
indicates "Single-Registration-Indication". The MME capabilities indicate the MME's support for regional 
access restrictions functionality. Homogenous Support of IMS Over PS Sessions indicates whether or not "IMS 
Voice over PS Sessions" is supported homogeneously in all TAs in the serving MME. 

15. If the MME changes, then the HSS cancels any old MME. The HSS sends a Cancel Location (IMSI, 
Cancellation type) message to the old MME, with a Cancellation Type set to Update Procedure. 

16. The old MME removes the MM context. 

The old MME releases any local bearer resources and it deletes the EPS bearer resources by sending Delete 
Session Request (Cause, Operation Indication) messages to the Serving GW. The operation Indication flag is not 
set, that indicates that the S-GW shall not initiate a delete procedure towards the PDN GW. If ISR is activated 
then the cause indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old CN 
node by sending Delete Bearer Request message(s) to that CN node. 

The old MME acknowledges with a Cancel Location Ack (IMSI) message. 

17. The HSS cancels any old SGSN node as the ULR-Flags indicates "Single-Registration-Indication". The HSS 
sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN. The old SGSN removes the 
contexts. 

If the timer started in step 5 is not running, the old SGSN removes the MM context. Otherwise, the contexts are 
removed when the timer expires. It also ensures that the MM context is kept in the old SGSN for the case the UE 
initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. 



ETSI 



3GPP TS 23.401 version 1 0.3.0 Release 1 249 ETSI TS 1 23 401 V1 0.3.0 (201 1 -03) 

NOTE 9: In all other mobility scenarios a new CN node initiates only cancellation of an old CN node of the same 
type via HSS. In this scenario here (Gn/Gp SGSN to MME TAU) the new MME, by indicating single 
registration, initiates in addition the cancellation of the old Gn/Gp SGSN via HSS to make sure that any 
PDP contexts of the UE are properly released. MME and S4 SGSN release PDP/PDN contexts based on 
context transfer signalling. 

18. On receipt of Cancel Location, if the MS is PMM CONNECTED in the old SGSN, the old SGSN sends an lu 
Release Command message to the old SRNC 

19. When the data-forwarding timer has expired, the SRNS responds with an lu Release Complete message. 

20. The old SGSN acknowledges with a Cancel Location Ack (IMSI) message. 

21. The new MME validates the UE's presence in the (new) TA. If all checks are successful, the MME constructs an 
MM context for the UE, the HLR acknowledges the Update Location by sending Update Location Ack (IMSI, 
Subscription Data) message to the new MME. If the Update Location is rejected by the HSS, the MME rejects 
the TAU Request from the UE with an appropriate cause sent in the TAU Reject message to the UE. 

22. If due to regional subscription restrictions or access restrictions the UE is not allowed to access the TA: 

For UEs with ongoing emergency bearer services, the new MME accepts the Tracking Area Update Request 
and releases the non-emergency bearers as specified in clause 5.10.3. 

For all other cases, the new MME rejects Tracking Area Update Request with an appropriate cause to the UE 
and notifies the HSS of rejection (details of this notification is stage 3 detail). 

The new MME responds to the UE with a Tracking Area Update Accept (GUTI, TAJ-list, EPS bearer status, 
NAS sequence number, NAS-MAC, ISR Activated) message. Restriction list shall be sent to eNodeB as eNodeB 
handles the roaming restrictions and access restrictions in the Intra E-UTRAN case. 

If the "active flag" is set in the TAU Request message the user plane setup procedure can be activated in 
conjunction with the TAU Accept message. The procedure is described in detail in TS 36.300 [5]. The messages 
sequence should be the same as for the UE triggered Service Request procedure specified in clause 5.3.4.1 from 
the step when MME establishes the bearer(s). If the active flag is set the MME may provide the eNodeB with 
Handover Restriction List. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The 
EPS bearer status indicates the active bearers in the network. The UE removes any internal resources related to 
bearers not marked active in the received EPS bearer status. 

When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to 
"GUTI". 

NOTE 10:In the case of interoperation with Gn/Gp SGSNs, ISR Activated is never indicated by the MME as the 
SGSN does not support ISR, which the new MME recognises from Gn interface signalling that does not 
support ISR indications. 

23. If the GUTI was included in the TAU Accept message, the UE acknowledges the message by returning a 
Tracking Area Update Complete message to the MME. 

When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated 
in ECM-CONNECTED state, the MME releases the signalling connection with UE, according to clause 5.3.5. 

NOTE 1 l:The new MME may initiate E-RAB establishment (see TS 36.413 [36]) after execution of the security 
functions (step 5), or wait until completion of the TA update procedure. For the UE, E-RAB 
establishment may occur anytime after the TA update request is sent (step 2). 

24. The target MME calculates UE-AMBR as defined in clause 4.7.3. If the local UE-AMBR provided by the MME 
as defined in Annex E is different from the corresponding derived UE-AMBR, or the APN-AMBR mapped from 
the subscribed MBR is different from the subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. 
the subscribed QoS profile mapped according to Annex E) of the default bearer is different from the EPS 
Subscribed QoS profile received from the HSS, the new MME shall initiate Subscribed QoS Modification 
procedure as described in clause 5.4.2.2, Figure 5.4.2.2-1. 

In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME should not construct a bearer context. In the case of 
receiving the subscriber data from HSS, the new MME may construct an MM context and store the subscriber data for 



£75/ 



3GPP TS 23.401 version 1 0.3.0 Release 1 250 ETSI TS 1 23 401 VI 0.3.0 (201 1 -03) 

the UE to optimize signalling between the MME and the HSS. A reject shall be returned to the UE with an appropriate 
cause and the SI connection shall be released. Upon return to idle, the UE shall act according to TS 23.122 [10]. 

If the new MME is unable to update the bearer context in one or more P-GWs, the new MME shall deactivate the 
corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This 
shall not cause the MME to reject the tracking area update. 

The PDF Contexts shall be sent from old SGSN to new SGSN (MME) in a prioritized order, i.e. the most important PDF 
Context first in the SGSN Context Response message. (The prioritization method is implementation dependent, but 
should be based on the current activity). 

The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context from the P-GW and then store the new Maximum APN restriction value. 

If there are active EPS GBR bearers with maximum bitrate set to 0, the MME should initiate MME Initiated Dedicated 
Bearer Deactivation (as specified in clause 5.4.4.2) to deactivate the related EPS bearer Context. 

If the new MME is unable to support the same number of active bearer contexts as received from old SGSN, the new 
MME should use the prioritisation sent by old SGSN as input when deciding which bearer contexts to maintain active 
and which ones to delete. In any case, the new MME shall first update all contexts in one or more P-GWs and then 
deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated Bearer Deactivation 
Procedure". This shall not cause the MME to reject the tracking area update. 

NOTE 12: If MS (UE) was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward 
Relocation Request message as described in clause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking 
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state. 

If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access 
non-PS services until a successful location update is performed. 

The CAMEL procedure calls shall be performed, see refrrenced procedures in TS 23.078 [29]: 

CI) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

NOTE 13:This CAMEL handling is unmodified compared to pre-Rel-8. 

NOTE 14: CAMEL procedure calls C2 and C3 were omitted intentionally from this procedure since EPS does not 
support CAMEL procedure calls. 

D.3.7 E-UTRAN to GERAN A/Gb mode Inter RAT handover 
D.3.7.1 General 

The interoperation procedures describe information flows for Gn/Gp SGSNs and other EPS network elements. All 
messages between SGSN and MME, between SGSN and BSS, between SGSN and HSS and between SGSN and P-GW 
(GGSN in TS 43.129 [8]) as well as the therein contained information elements are the same as specified for the 
adequate TS 43.129 [8] procedures. These messages and procedure step descriptions are taken from TS 43.129 [8] for 
explanatory purposes only. These descriptions are in italic text and shall not be modified by the interoperation 
procedures. It cannot be assumed that the messages and procedure step descriptions that are taken from TS 43.129 [8] 
will be updated when modifications or corrections are performed for TS 43.129 [8]. If there are any discrepancies for 
these messages and procedure step descriptions TS 43.129 [8] takes precedence. 
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The messages between the MME and any other node than the Gn/Gp SGSN as well as the therein contained information 
elements are the same as specified in the main body of this technical specification for the IRAT handover E-UTRAN 
to/from GERAN A/Gb mode procedure (clauses 5.5.2.3 and 5.5.2.4). These descriptions are in bold italic text and shall 
be modified simultaneously when clauses 5.5.2.3 or 5.5.2.4 are updated. 

D.3.7.2 Preparation phase 
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Figure D.3.7.2-1 : E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase 

1. The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. 
At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and 
Source eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW. 

If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to GERAN. 

NOTE 1: The process leading to the handover decision is outside of the scope of this specification 

2. The source eNodeB sends a Handover Required (Cause, Target System Identifier, Source BSS to Target BSS 
Transparent Container) message to the Source MME to request the CN to establish resources in the Target 
BSS, Target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are 
identified by the new SGSN in a later step (see step 8 below). 

The 'Target System Identifier' IE contains the identity of the target global cell Id. 

NOTE 2: This step is unmodified compared to clause 5.5.2.3.2. The target SGSN acts as the new SGSN. 

3 The old SGSN determines from the Target Cell Identifier that the type of handover is inter-RAT/mode handover. 
In case of Inter-RAT/ mode Inter-SGSN PS handover, the old SGSN initiates the PS Handover resource 
allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Control 
Plane, RANAP Cause, Target Cell Identifier, MM Context, PDP Contexts, Packet Flow ID, SNDCP XID 
parameters, LLC XID parameters, PDP Context Prioritisation, Source BSS To Target BSS Transparent 
Container [RN part] in the BSS Container, Source RNC Id, SGSN Address for control plane) message to the new 
SGSN. If the old SGSN supports PS handover procedures then it has to allocate a valid PFI according to 
clause 4.4.1 during the PDP Context activation procedure. Each PDP context contains the GGSN Address for 
User Plane and the Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data the old SGSN and 
the new SGSN send uplink packets). 

The MM context contains security related information, e.g. supported ciphering algorithms as described in 
TS 29.060 [14]. The relation between GSM and UMTS security parameters is defined in TS 33.102 [40], 
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The new SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the new 
SGSN to the MS. The lOV-UI parameter generated in the new SGSN and used, as input to the ciphering 
procedure will also be transferred transparently from the new SGSN to the MS. 

When the new SGSN receives the Forward Relocation Request message the required PDF, MM, SNDCF and 
LLC contexts are established and a new F-TMSI is allocated for the MS. When this message is received by the 
new SGSN it begins the process of establishing FFCs for all FDF contexts. 

When the new SGSN receives the Forward Relocation Request message it extracts from the PDF Contexts the 
NSAFIs and SAFIs and FFIs to be used in the new SGSN. If for a given FDF Context the new SGSN does not 
receive a FFIfrom the old SGSN, it shall not request the target BSS to allocate TBF resources corresponding to 
that FDF Context. If none of the FDF Contexts forwarded from the old SGSN has a valid FFI allocated the new 
SGSN shall consider this as a failure case and the request for FS handover shall be rejected. 

In case when an SAFI and FFI was available at the old SGSN but the new SGSN does not support the same SAFI 
and FFI for a certain NSAFI as the old SGSN, the new SGSN shall continue the FS handover procedure only for 
those NSAFIs for which it can support the same FFI and SAFI as the old SGSN. All FDF contexts for which no 
resources are allocated by the new SGSN or for which it cannot support the same SAFI and FFI (i.e. the 
corresponding NSAFIs are not addressed in the response message of the target SGSN), are maintained and the 
related SAFIs and FFIs are kept. These FDF contexts may be modified or deactivated by the new SGSN via 
explicit SM procedures upon RAU procedure. 

The old SGSN shall indicate the current XID parameter settings if available (i.e. those negotiated at the old 
SGSN when the MS was in A/Gb mode or received during a previous inter-SGSN FS handover) to the new 
SGSN. If the new SGSN can accept all XID parameters as indicated by the old SGSN, the new SGSN shall create 
a NAS container for FS HO indicating 'Reset to the old XID parameters '. Otherwise, if the new SGSN cannot 
accept all XID parameters indicated by the old SGSN or if no XID parameters were indicated by the old SGSN, 
the new SGSN shall create a NAS container for FS HO indicating Reset (i.e. reset to default parameters). 

NOTE 3: This step is unmodified compared to pre-Rel-8. The Source eNodeB acts as the source RNC, Source 
MME acts as the old SGSN, and the PDN GW acts as the GGSN. 

4. The new SGSN sends a FS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, Source BSS to 
Target BSS Transparent Container (RN part), FFCs To Be Set Up List, NAS container for FS HO) message to 
the target BSS. The new SGSN shall not request resources for FFCs associated with FDF contexts with 
maximum bit rate for uplink and downlink ofO kbit/s or for which the Activity Status Indicator within the FDF 
Context indicates that no active RAB exists on the source side. 

5. Based upon the ABQF for each FFC the target BSS makes a decision about which FFCs to assign radio 
resources. The algorithm by which the BSS decides which FFCs that need resources is implementation specific. 
Due to resource limitations not all downloaded FFCs will necessarily receive resource allocation. The target 
BSS allocates TBFs for each FFC that it can accommodate. 

6. The target BSS shall prepare the Target BSS to Source BSS Transparent Container which contains a FS 
Handover Command including the CN part (NAS container for FS HO) and the RN part (FS Handover Radio 
Resources). 

7. Target BSS shall send the FS Handover Request Acknowledge message (Local TLLI, List of Set Up FFCs, Target 
BSS to Source BSS Transparent Container) message to the new SGSN. Upon sending the FS Handover Request 
Acknowledge message the target BSS shall be prepared to receive downlink LLC FDUs from the new SGSN for 
the accepted FFCs. 

Any FDF contexts for which a FFC was not established are maintained in the new SGSN and the related SAFIs 
and FFIs are kept. These FDF contexts may be modified or deactivated by the new SGSN via explicit SM 
procedures upon the completion of the routing area update (RAU) procedure. 

8. The new SGSN passes the assigned list of TEIDs for each FDF context for which a FFC was assigned in the 
RAB setup information IE in the Forward Relocation Response (Cause, List of Set Up FFCs, Target BSS to 
Source BSS Transparent Container) in the BSS Container, Tunnel Endpoint Identifier Control Flane, SGSN 
Address for User Traffic, Tunnel Endpoint Identifier Data II) message to the old SGSN. The NSAFIs of the active 
FDF Contexts received in the Forward Relocation Request message for which the FS handover continues, i.e. 
for which resources are allocated for the FFCs in the target BSS, are indicated in this message. 
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The Tunnel Endpoint Identifier Data II, one information for each PDF context, is the tunnel endpoint of the new 
SGSN and is used for data forwarding from the Source eNodeB, via the new SGSN, to the target BSS. 

The new SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064 [23] for an SGSN 
originated Reset or 'Reset to the old XID parameters'. 

When the old SGSN receives the Forward Relocation Response message and it decides to proceed with the 
handover, the preparation phase is finished and the execution phase will follow. 

9. If 'Indirect Forwarding' applies, the source MME sends a Create Indirect Data Forwarding Tunnel Request 
message (Cause, SGSN Address(es) and TEID(s) for Data Forwarding) to the Serving GW. Cause indicates 
that the bearer(s) are subject to data forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

9a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW 
Address(es) and TEID(s) for Data Forwarding) message to the target MME. If the Serving GW doesn't 
support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and 
TEID(s) will not be included in the message. 

NOTE 4: This step is mostly unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN, and the 
PDN GW acts as the GGSN. 
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D.3.7.3 Execution phase 
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Figure D.3.7.3-1 : E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase 

The source eNodeB continues to receive downlink and uplink user plane PDUs. 

1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover 
Command (Target BSS to Source BSS Transparent Container (PS Handover Command with RN part and EPC 
part), Bearers Subject to Data Forwarding List). The "Bearers Subject to Data forwarding list" may be included 
in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from 
target side in the preparation phase (Forward Relocation Response message (Step 8)). 

Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding goes directly to target SGSN decided in the preparation phase. 

2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message 
HO from E-UTRAN Command. This message includes a transparent container including radio aspect 
parameters that the Target BSS has set-up in the preparation phase (RN part). This message also includes the 
XID and lOV-UI parameters received from the Target SGSN (EPC part). 
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Upon the reception of the HO from E-UTRAN Command message containing the Handover Command 
message, the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI 
and shall suspend the uplink transmission of the user plane data. 

NOTE 1: This step is unmodified compared to clause 5.5.2.3.3. The target SGSN acts as the new SGSN. 

3. Void. 

NOTE 2: The source eNodeB does not send any RAN context towards the target BSS. 

4. The MS executes the handover according to the parameters provided in the message delivered in step 2. The 
procedure is the same as in step 6 in clause 5.1.4.2 in TS 43.129 [8] with the additional function of association 
of the received PFI and existing RAB Id related to the particular NSAPI as described in clause 4.4.1 in 

TS 43.129 [8]. 

The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer 
context activated after the ISR was activated in the UE exists. 

5/7. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 2, 
the MS processes the NAS container and then sends one XID Response message to the new SGSN. The MS sends 
this message immediately after receiving the Packet Physical Information message containing the timing 
advance or, in the synchronised network case, immediately if the PS Handover Access message is not required to 
be sent (see clause 6.2 in TS 43.129 [8]). 

Upon sending the XID Response message, the MS shall resume the user data transfer only for those NSAPIs for 
which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM for which radio 
resources were not allocated in the target cell the MS may request for radio resources using the legacy 
procedures. 

NOTE 3: If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO 

included in the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN lu 
Command message, in order to avoid collision cases the mobile station may avoid triggering XID 
negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any 
case the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but 
wait for the SGSN to do so (see step 12a). 

NOTE 4: This step is unmodified compared to pre-Rel-8. The message "HO from E-UTRAN Command" acts as 
the "Handover from UTRAN Command" message (UTRAN) or the "Handover from GERAN lu 
Command" message. 

6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the target BSS 
sends a PS Handover Complete (Local TLLI, Handover Complete Status) message to inform the new SGSN that 
the MS has arrived in the target cell. Each uplink N-PDU received by the new SGSN via the target BSS is then 
forwarded directly to the GGSN. 

A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall 
be released. 

NOTE 5: This step is unmodified compared to pre-Rel-8. The PDN GW acts as the GGSN. 

8. Upon receiving the PS Handover Complete message, the new SGSN send a Forward Relocation Complete 

message to the old SGSN to indicate completion of the PS handover procedures. The old SGSN responds with a 
Forward Relocation Complete Acknowledge message. 

NOTE 6: This step is unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN. 

9/77. The new SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message 
to the GGSN concerned. The GGSN updates the PDP context fields and returns an Update PDP Context 
Response (TEID) message. From now on the GGSN sends new incoming downlink IP packets to the new SGSN 
instead of to the old SGSN. 

The PDN GW shall include a Charging Id to be used at the SGSN as the Charging ID for reporting usage for this 
PDP context. The PDN GW shall include the Charging Id in the offline charging data. 
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NOTE 7: This step is unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN, and the 
PDN GW acts as the GGSN. 

12. If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in 
the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN lu Command message, 
then on receipt of the PS Handover Complete the new SGSN initiates an LLC/SNDCP XID negotiation for each 
LLC SAPI used in LLC ADM. In this case if the SGSN wants to use the default parameters, it shall send an empty 
XID Command. If the new SGSN indicated 'Reset to the old XID parameters ' in the NAS container for PS HO, no 
further XID negotiation is required for LLC SAPIs used in LLC ADM only. 

NOTE 8: This step is unmodified compared to pre-Rel-8. The message "HO from E-UTRAN Command" acts as 
the "Handover from UTRAN Command" message (UTRAN) or the "Handover from GERAN lu 
Command" message. 

12a. The new SGSN (re-)establishes LLC ABM for the PDP contexts which use acknowledged information 
transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation. 

13. The MS sends a Routing Area Update Request (Old P-TMSI, Old RAI, Old P-TMSI signature. Update Type) 
message to the new SGSN informing it that the source cell belongs to a new routing area. The MS shall send this 
message immediately after message 5, see TS 23.060 [7]. 

The new SGSN knows that a handover has been performed for this MS and can therefore exclude the SGSN 
context procedures which normally are used within the RA Update procedure. 

For further descriptions of the Routing Area Update procedure see TS 43.129 [8], clauses 5.5.2.3 and 5.6.1.1.1. 

NOTE 9: The RAU procedure is performed regardless if the routing area is changed or not, as specified by 
TS 43.129 [8]. 

14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source 
eNodeB. The Source eNodeB releases its resources related to the UE. 

Additionally, the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause, 
Operation Indication) messages to the Serving GW. The operation Indication flag is not set, that indicates to the 
Serving GW that it shall not initiate a delete procedure towards the PDN GW. The Serving GW acknowledges 
with Delete Session Response (Cause) messages. If ISR is activated then the cause indicates to the old Serving 
GW that the old Serving GW shall delete the bearer resources on the other old CN node by sending Delete 
Bearer Request message(s) to that CN node. 

15. When the timer started in step 8 expires and if resources for indirect forwarding have been allocated then they 
are released. 

D.3.8 GERAN A/Gb mode to E-UTRAN Inter RAT handover 
D.3.8.1 General 

See clause D.3.7.1. 
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D.3.8.2 Preparation phase 
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Figure D.3.8.2-1 : GERAN A/Gb mode to E-UTRAN inter RAT HO, preparation phase 

1. The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is transmitted 
via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between source BSS and old SGSN, 
GTP tunnel(s) between old SGSN and GGSN. 

NOTE 1: The MS acts as UE, and the PDN GW acts as the GGSN. 

2. The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target 
eNodeB Identifier, Source to Target Transparent Container (RN part), and active PFCs list) to Source SGSN 
to request the CN to establish resources in the Target eNodeB, Target MME and the Serving GW. 

NOTE 2: The Source SGSN acts as the Old SGSN. 

NOTE 3: As an implementations option for supporting introduction scenarios with pre-Rel8 SGSNs the source BSS 
may be configured to use RNC IDs instead of eNodeB IDs to identify a target eNodeB. The Cause is 
relayed transparently by the SGSN to the MME and the MME mappes the BSSGP cause code to an SlAP 
cause code. Source to Target Transparent Container carries information for the target eNodeB. This 
container is relayed transparently by the SGSN. 

3. The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS 
Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending 
message Forward Relocation Request (IMSI, Target Identification, MM Context, PDP Context, SGSN 
Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane. Source to Target 
Transparent Container (RN part). Packet Flow ID, SNDCP XID parameters, LLC XID parameters) to the 
target MME. This message includes all PDP contexts that are established in the source system indicating the 
PFIs and the XID parameters related to those PDP Contexts, and the uplink Tunnel endpoint parameters of 
the Serving GW. 

The PDP Contexts shall be sent in a prioritized order, i.e. the most important PDP Context first. The 
prioritization method is implementation dependent, but should be based on the current activity. 

NOTE 3: Assigning the highest priority to the PDP context without TFT could be done to get service continuity 
for all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The target MME maps the PDP contexts to the EPS bearers I-to-I and maps the Release 99 QoS parameter 
values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer as defined in Annex E. 
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The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which 
cannot be established. 

The MM context contains security related information, e.g. supported ciphering algorithms as described in 
TS 29.060 [14]. 

For the PDP Context with traffic class equals 'Background', the source SGSN shall indicate via the Activity 
Status Indicator IE that EPS bearers shall be established on the target side. 

NOTE 4: The Source SGSN acts as the old SGSN. 

4. The target MME selects the Serving GW as described under clause 4.3.8.2 on "Serving GW selection function". 
The target MME sends a Create Session Request message (IMSI, MME Tunnel Endpoint Identifier for Control 
Plane, MME Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user 
plane, PDN GW address for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over 
S5/S8, APN-AMBR, Serving Network) per PDN connection to the Serving GW. The Protocol Type over S5/S8 
is provided to Serving GW which protocol should be used over S5/S8 interface. For relocation from Gn/Gp 
SGSN, the target MME provides the APN-AMBR if not received explicitly from the Gn/Gp SGSN based on the 
mapping from MBR (as specified in Annex E) to the Serving GW 

4a. The Serving GW allocates its local resources and returns them in a Create Session Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEW for control plane) message to the target MME. 

5. The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover 
Request (UE Identifier, SIAP Cause, Integrity protection information (i.e. IK and allowed Integrity 
Protection algorithms). Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to 
be setup list. Source to Target Transparent Container). The Target MME shall not request resources for 
which the Activity Status Indicator within a PDP Context indicates that no active bearer exists on the source 
side for that PDP Context. 

For each EPS bearer requested to be established, 'EPS Bearers To Be Setup ' IE shall contain information 
such as ID, bearer parameters. Transport Layer Address, "Data forwarding not possible " indication and SI 
Transport Association. The Transport Layer Address is the Serving GW Address for user data, and the SI 
Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. "Data forwarding not 
possible " indication shall be included if the target MME decides the corresponding bearer will not be subject 
to data forwarding. 

The target MME shall not request the target eNodeB to establish EPS GBR bearers with maximum bitrate set to 
and those EPS bearers should not be included in the EPS Bearers to be setup list and should be deactivated by 
the MME. For the remaining EPS Bearer Contexts the MME ignores any Activity Status Indicator within an EPS 
Bearer Context and requests the target eNodeB to allocate resources for all the remaining EPS Bearer Contexts. 

The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the 
Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the 
UE. This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new 
AKA (Authentication and Key Agreement) procedure. 

The MME shall compute the UE-AMBR, as per clause 4.7.3, based on explicit APN-AMBR values received 
from the Gn/Gp SGSN. If explicit APN-AMBR values are not received by the MME, a local UE-AMBR shall be 
included in the 'EPS Bearers be setup list ' IE. The local UE-AMBR is described in Annex E. 

5a. The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME 
in the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup 
list, EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message the target 
eNodeB shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS bearers. 

The target eNodeB shall ignore it if the number of radio bearers in the Source to Target Transparent container 
does not comply with the number of bearers requested by the MME and allocate bearers as requested by the 
MME. 

6. If 'Indirect Forwarding' applies, the target MME sends a Create Indirect Data Forwarding Tunnel Request 
message (Cause, Target eNodeB Address(es), TEID(s) for DL user plane) to the Serving GW. Cause indicates 
that the bearer(s) are subject to data forwarding. 
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6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW 
Address(es) and TEID(s) for Data Forwarding) message to the target MME. If the Serving GW doesn't 
support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and 
TEID(s) will not be included in the message. 

7. The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PFCs, MME 
Tunnel Endpoint Identifier for Control Plane, BSSGP cause, MME Address for control plane. Target to 
Source Transparent Container, Address(es) and TEID(s) for Data Forwarding) to the Source SGSN. 

If 'Direct Forwarding' is applicable, then the lEs 'Address(es) and TEID(s) for Data Forwarding' contains the DL 
GTP-U tunnel endpoint parameters to the eNodeB. If 'Indirect Forwarding' applies the IBs 'Address(es) and 
TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the Serving GW. 

NOTE 5: The Source SGSN acts as the old SGSN. 



D.3.8.3 Execution phase 
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13. Procedure as in TS 23.401, steps 2 to 7 of Figure 5.4.2.2-1 

I I 

Figure D.3.8.3-1 : GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 9a concern GTP 
based S5/S8. 

The old SGSN continues to receive downlink and uplink user plane PDUs. 
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When old SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and 
duplication to the target eNodeB, and the target eNodeB may start blind transmission of downlink user data towards the 
UE over the allocated radio channels. 

1. The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO 
Required Acknowledge (TLLI, List of Set Up PFCs, Target to Source Transparent Container). This message 
includes all PFIs that could be established on the Target side. 

Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink 
data transfer for any PDP contexts. 

Before sending the PS Handover Command message to the UE the source BSS, may try to empty the 
downlink BSS buffer for any BSS PFCs. 

NOTE 2: The Source SGSN acts as the old SGSN. 

2. The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover 
Command. The access system specific message to UE includes a transparent container including radio aspect 
parameters that the Target eNodeB has set-up in the preparation phase. 

3. There is no RAN context transfer during inter RAT handovers with E-UTRAN. If the source SGSN originates 
any SRNS contexts the MME acknowledges the receipt towards the SGSN and ignores the message content. 

4. The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB. 

5. When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete. The UE shall 
implicitly derive the EPS bearers for which an E-RAB was not established from the PS Handover Command 
and deactivate them locally without an explicit NAS message at this step. 

6. When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by 
sending the message Handover Notify. 

Upon receipt of the Handover Notify message the target MME starts a timer if the target MME applies indirect 
forwarding. 

7. Then the Target MME knows that the UE has arrived to the target side and Target MME informs the old SGSN 
by sending the Forward Relocation Complete () message. The old SGSN will also acknowledge that information. 
When the Forward Relocation Complete message has been received and there is no longer any need for the Old 
SGSN to forward data, the old SGSN stops data forwarding. A timer in old SGSN is started to supervise when 
resources shall be released. 

8. The Target MME will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the Target MME is now responsible for all the EPS 
bearers the UE have established. This is performed in the message Modify Bearer Request (Cause, MME 
Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB 
Address(es) and TEID(s) for User Traffic for the accepted EPS bearers, PDN GW addresses and TEIDs (for 
GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s)for uplink traffic and RAT type) 
per PDN connection. 

In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the 
DL packet and does not send a Downlink Data Notification to the MME. 

NOTE 3: The text regarding "Target Serving GW" shall be ignored. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) informs the PDN GW(s) the 
change of, for example, for Serving GW relocation or the RAT type, that e.g. can be used for charging, by 
sending the message Modify Bearer Request per PDN connection. Serving Network should be included in this 
message if it is received in step 4. For Serving GW relocation, the Serving GW allocates DL TEIDs on S5/S8 
even for non-accepted bearers. The PDN GW must acknowledge the request with the message Modify Bearer 
Response (APN Restriction). When the UE moves from Gn/Gp SGSN to the MME, the PDN GW shall send 
the APN restriction of each bearer context to the Serving GW. 

IfPCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT 
type. 
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The Modify Bearer Response also indicates the identity of the default bearer and the Charging Id towards the 
S-GW. 

NOTE 4: The text regarding "Target Serving GW" shall be ignored. 

10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the Target MME via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW (for Serving GW relocation this will be the Target Serving GW) 
Address for Control Plane, Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s)for uplink traffic, APN Restriction).The 
Serving GW shall forward the received APN Restriction to the MME. At this stage the user plane path is 
established for all bearers between the UE, Target eNodeB, Serving GW (for Serving GW relocation this will 
be the Target Serving GW) and PDN GW. 

In addition, the Modify Bearer Response indicates the identity of the default bearer towards the MME. 

11. When the timer started in step 7 expires the Source SGSN will clean-up all its resources towards Source BSS 
by performing the BSS Packet Flow Delete procedure. 

When the timer started in step 6 expires the target MME releases the resources that have been allocated for 
indirect forwarding. 

NOTE 5: The text regarding "Target Serving GW" shall be ignored. 

12. The RAN triggers the UE to initiate a Tracking Area Update procedure with the target MME. It is RAN 
functionality to provide the ECM CONNECTED UE with the trigger information. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. 

The target MME gets the subscribed UE-AMBR value and the subscribed APN-AMBR value from the HSS 
during the TA update procedure. 

13. The target MME calculates UE-AMBR as defined in clause 4.7.3. If this calculated value is different from the 
UE-AMBR computed during step 6, or the APN-AMBR mapped from the subscribed MBR is different from the 
subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. the subscribed QoS profile mapped 
according to Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the 
HSS, the new MME shall initiate Subscribed QoS Modification procedure as described in clause 5.4.2.2, Figure 
5.4.2.2-1 
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Annex E (normative): 

Mapping between EPS and Release 99 QoS parameters 

This annex specifies how the QoS parameter values of an EPS bearer are mapped to/from the Release 99 QoS parameter 
values of a PDP context in PDN-GW, S4-SGSN and MME. 

The following mapping rules hold: 

There is a one-to-one mapping between an EPS bearer and a PDP context. 

When EPS bearer QoS parameters are mapped to Release 99 QoS parameters the pre-emption capability and the 
pre-emption vulnerability information of the EPS bearer ARP are ignored and the priority of the EPS bearer 
parameter ARP is mapped to the Release 99 bearer parameter ARP, as described in table E. 1 . 

Table E.I : Mapping of EPS bearer ARP to Release 99 bearer parameter ARP 

• EPS • Release 99 bearer 

• Bearer ARP parameter 
Priority Value • ARP Value 

. 1 to H .1 

• H+1 to M .2 

• M+1 to 15 • 3 

When Release 99 QoS parameters are mapped to EPS bearer QoS parameters the pre-emption capability and the 
pre-emption vulnerability information of the EPS bearer ARP are set based on operator policy in the entity that 
performs the mapping. The Release 99 bearer parameter ARP is mapped to the priority level information of the 
EPS bearer parameter ARP as described in table E.2. 

Table E.2: Mapping of Release 99 bearer parameter ARP to EPS bearer ARP 

• Release 99 • EPS 
bearer parameter • Bearer ARP 

• ARP Value Priority Value 

• 1 .1 

• 2 • H+1 

• 3 • M+1 

The values of H (high priority) and M (medium priority) can be set according to operator requirements to ensure 
proper treatment of users with higher priority level information. The minimum value of H is 1 . The minimum 
value of M is H+1. 

From Release 9 onwards, the priority of the EPS bearer parameter ARP is mapped one-to-one to/from the 
Evolved ARP parameter of a PDP context, if the network supports this parameter. 

NOTE 1 : The setting of the values for H and M may be based on the SGSN mapping from the Release 99 bearer 
parameter ARP to the ARP parameter that is used for UTRAN/GERAN. 

NOTE 2: After a handover from UTRAN/GERAN to E-UTRAN the ARP parameter of the EPS bearer can be 

modified by the P-GW to re-assign the appropriate priority level, pre-emption capability and pre-emption 
vulnerability setting. 

NOTE 3: A mapping from the EPS bearer parameter ARP to the Release 99 bearer parameter ARP is not required 
for a P-GW when connected to an SGSN via Gn/Gp as any change of the bearer ARP parameter may get 
overwritten by the SGSN due to subscription enforcement. However, the P-GW should not combine 
services with different EPS bearer ARP values onto the same PDP context to enable a modification of the 
bearer ARP without impacting the assignment of services to bearers after a handover to E-UTRAN. 

The EPS bearer parameters GBR and MBR of a GBR EPS bearer are mapped one-to-one to/from the Release 99 
bearer parameters GBR and MBR of a PDP context associated with Traffic class 'conversational' or 'streaming'. 

When EPS bearer QoS parameters are mapped to Release 99 QoS parameters the Release 99 bearer parameter 
MBR of PDP contexts associated with Traffic Class 'interactive' or 'background' is set equal to the value of the 
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authorized APN-AMBR. If the APN-AMBR is modified while the UE accesses the EPS through E-UTRAN, the 
UE shall also set the Release 99 bearer parameter MBR to the new APN-AMBR value for all non-GBR PDP 
contexts of this PDN connection. The P-GW shall enforce the APN-AMBR across all PDP contexts with Traffic 
Class 'interactive' and 'background' for that APN. The MME or S4-SGSN may attempt to transfer APN-AMBR 
and UE-AMBR to a Gn/Gp SGSN 

When Release 99 QoS parameters are mapped to EPS bearer QoS parameters the AMBR for the corresponding 
APN shall be set equal to the MBR value of the subscribed QoS profile. At handover from a Gn/Gp SGSN the 
MME or S4-SGSN shall provide this APN-AMBR value, if not explicitly received from the Gn/Gp SGSN, to the 
Serving GW and the PDN GW for each PDN connection. It is required that the subscribed MBR in the 
HLR/HSS is set to the desired APN-AMBR value for all subscribed APNs which may lead to a selection of a 
P-GW. The UE derives the APN-AMBR from the value of the MBR of a PDP context created by the PDP 
Context Activation Procedure as described in TS 23.060 [7]. 

NOTE 5: If the pre-Rel-8 UE with the updated subscribed MBR is connected to a GGSN, the GGSN can 

downgrade the MBR of the PDP contexts based on either local policy or PCC (where the MBR per QCI 
information is provided to the PCEF). 

NOTE 6: From Release 9 onwards, the APN-AMBR is available on Gn/Gp. 

- For handover from a Gn/Gp SGSN and if the MME does not receive AMBR values from the Gn/Gp SGSN, the 
MME provides a local UE-AMBR to the eNodeB until MME gets the EPS subscribed UE-AMBR. When the 
MME gets the subscribed UE-AMBR value from the HSS, it calculates the UE-AMBR (UE- 
AMBR=MIN(subscribed UE-AMBR, sum APN-AMBR of all active APNs)). Then it compares this value with 
the local UE-AMBR and of the local UE-AMBRs is different from the corresponding derived UE-AMBR, the 
MME initiates HSS Initiated Subscribed QoS Modification procedure to notify the derived UE-AMBR to the 
eNodeB. 

NOTE 7: The local UE-AMBR may be for example based on the summing up of the APN-AMBR values of all a 
active APNs of the UE or on internal configuration. 

A standardized value of the EPS bearer parameter QCI is mapped one-to-one to/from values of the Release 99 
parameters Traffic Class, Traffic Handling Priority, Signalling Indication, and Source Statistics Descriptor as 
shown in Table E.3. 

NOTE 8: When mapping to QCI=2 or QCI=3, the Release 99 parameter Transfer Delay is used in addition to the 
four Release 99 parameters mentioned above. 

When EPS bearer QoS parameters are mapped to Release 99 QoS parameters the setting of the values of the 
Release 99 parameters Transfer Delay and SDU Error Ratio is derived from the corresponding QCI's Packet 
Delay Budget and Packet Loss Rate, respectively. When Packet Loss Rate parameter is further mapped to 

Release 99 QoS parameter Reliability Class (TS 23.107 [59], table 7), the Residual BER is considered <= 2*10" 
4 
. Also when Release 99 QoS parameters are mapped to EPS bearer QoS parameters the values of the Release 99 

parameter SDU Error Ratio are ignored. 

The setting of the values of all other Release 99 QoS is based on operator policy pre-configured in the MME and 
S4-SGSN. 

- In networks that support mobihty from E-UTRAN to UTRAN/GERAN, if the UE has indicated support of 
UTRAN or GERAN, the EPS network shall provide the UE with the Release 99 QoS parameters in addition to 
the EPS bearer QoS parameters within EPS bearer signalling. 
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Table E.3: Mapping between standardized QCIs and Release 99 QoS parameter values 



QCI 


• Traffic 
Class 


• Traffic 
Handii 

ng 
Priorit 

y 


• Signalling 
Indication 


■1 
• 2 


• Conversational 

• Conversational 


. N/A 
. N/A 


. N/A 
. N/A 



• 3 • Conversational • N/A • N/A 



• 4 • Streaming • N/A • N/A 

• 5 • Interactive • 1 • Yes 

• 6 • Interactive '1 "No 

• 7 • Interactive '2 "No 

• 8 • Interactive • 3 "No 

• 9 • Background • N/A • N/A 

N0TE°1 : When QCI 2 is mapped to Release 99 QoS parameter values, the Transfer Delay parameter 
ms. When Release 99 QoS parameter values are mapped to a QCI, QCI 2 is used for conversational/un 
Transfer Delay parameter is greater or equal to 1 50 ms. 

N0TE°2: When QCI 3 is mapped to Release 99 QoS parameter values, the Transfer Delay parameter 
ms as the lowest possible value, according to TS 23.107 [59]. When Release 99 QoS parameter values 
to a QCI, QCI 3 is used for conversational/unknown if the Transfer Delay parameter is lower than 1 50 m 
NQTE 3: When QCI 4 is mapped to Release 99 QoS parameter values, it is mapped to Streaming/Unk 
Release 99 QoS parameter values are mapped to a QCI, Streaming/Unknown and Streaming/Speech a 
mapped to QCI 4. 
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Annex F (normative): 

Dedicated bearer activation in combination with the default 
bearer activation at Attach and UE requested PDN 
connectivity procedures 

It shall be possible for the PDN GW to initiate the activation of dedicated bearers (as specified in clause 5.4.1) as part of 
the attach procedure (as specified in clause 5.3.2. 1) or as part of the UE requested PDN connectivity procedure (as 
specified in clause 5.10.2) over E-UTRAN. However, the result of the dedicated bearer activation procedure shall be 
logically separate from the Attach procedure, meaning that the result of the Attach procedure is not dependent on 
whether the Dedicated bearer activation procedure succeeds or not. On the other hand, the dedicated bearer activation 
may only be regarded as successful if the Attach procedure completes successfully. 

The messages of the Dedicated bearer activation can be sent together with the messages of the Attach procedure or of 
the UE requested PDN connectivity procedure (i.e. Attach accept or PDN Connectivity Accept), as shown in the Figure 
and explanation below. 

On the S 1 and Uu interfaces the messages for the default bearer activation at Attach and UE requested PDN 
connectivity procedures and for the Dedicated Bearer Activation procedure are combined into a single message. If the 
MME has sent an Attach Accept message towards the eNodeB, and then the MME receives a Create Bearer Request 
before the MME receives the Attach Complete message, the MME shall wait for the Attach procedure to complete 
before the MME continues with Dedicated Bearer Activation procedure. 

It shall be possible that multiple dedicated bearers can simultaneously be activated in the signalling flow shown below. 
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Figure F.I : Dedicated bearer activation in combination with the default bearer activation at attach or 

UE requested PDN connectivity 

NOTE 1: Parameters related to dedicated bearer activation are written in italics. 

Figure F. 1 describes the activation of dedicated bearer(s) in combination with the default bearer activation either as part 
of the Attach procedure (with specific steps la, 7a, 10a) or as part of the UE requested PDN connectivity procedure 
(with specific steps lb, 7b, 10b). The following steps below require special attention: 

5. (On the P-GW-S-GW interface) Create Session Response message of the Attach procedure or UE-requested 
PDN connectivity procedure is combined with Create Bearer Request message of the Dedicated Bearer 
Activation Procedure 
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6. (On the S-GW-MME interface) Create Session Response message of the Attach procedure or UE-requested PDN 
connectivity procedure is combined with the Create Bearer Request message of the Dedicated Bearer Activation 
Procedure 

7a. For Attach procedure: If the MME receives a Create Session Response message combined with a Create Bearer 
Request message, the MME shall send the Sl-AP Initial Context Setup Request message to the eNodeB, 
including the NAS parts for both the Attach Accept message of the Attach procedure and the Bearer Setup 
Request of the Dedicated Bearer Activation Procedure. 

NOTE 2: The MME shall not send a Bearer Setup Request message of a new Dedicated Bearer Activation 
procedure to the eNodeB before sending the Attach Accept message of the Attach procedure to the 
eNodeB. If the MME has already sent the Attach Accept message of the Attach procedure to the eNodeB, 
the MME shall wait for the Attach Complete message to arrive before sending a separate Bearer Setup 
Request of a Dedicated Bearer Activation procedure. 

7b. For UE requested PDN connectivity procedure: If the MME receives a Create Session Response message 

combined with a Create Bearer Request message, the MME shall send the Sl-AP Bearer Setup Request message 
to the eNodeB, including the NAS parts for both the PDN Connectivity Accept message and the Bearer Setup 
Request of the Dedicated Bearer Activation Procedure. 

8-9. The radio bearer establishment of the default and dedicated bearer(s) is performed in the same RRC message. 

10a. For Attach procedure: The eNodeB sends the Sl-AP Initial Context Setup Response message to the MME. 

10b. For UE requested PDN connectivity procedure: The eNodeB sends the Sl-AP Bearer Setup Response 
message to the MME. 

11. For the Attach procedure: The UE sends the eNodeB a Direct Transfer message containing the Attach Complete 
(Session Management Response for the Default Bearer) message as response of the attach procedure, and Direct 
Transfer messages containing the Session Management Responses of the dedicated bearer setup procedure. 

For the UE requested PDN connectivity procedure: The UE NAS layer builds a PDN Connectivity Complete 
(Session Management Response) for the Default Bearer Activation and Dedicated Bearer Activation Procedures. 
The UE then sends Direct Transfer (PDN Connectivity Complete) message to the eNodeB. 

The NAS messages to establish the EPS bearers shall be handled individually by the UE and be sent in separate 
RRC Direct Transfer messages. 

12. The eNodeB sends an Uplink NAS Transport message to the MME, which contains the NAS messages from the 
RRC message in step 1 1 . There may be multiple Uplink NAS Transport messages when the UE sends multiple 
RRC messages containing NAS messages in step 11. 

13. Upon reception of the response messages in both step 10 and step 12, the Modify Bearer Request message of the 
Attach procedure or UE requested PDN connectivity procedure is combined with the Create Bearer Response 
message of the Dedicated Bearer Activation Procedure. After that, the Serving GW continues with sending a 
Create Bearer Response message to the PDN GW. 
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Annex G: 
Void 
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Annex H (normative): 

Mapping between temporary and area identities 

The mapping between temporary and area identities is defined in TS 23.003 [9]. 
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Annex I (informative): 

Guidance for contributors to this specification 

The following guidance is provided for drafting figures for this specification TS 23.401 that contain specific steps 
which are different in TS 23.402 [2] due to the PMIP-based S5/S8 interface: 

Message flows to this specification will contain the complete procedures applicable for GTP-based S5/S8 only. 

In this specification, clause(s) of a message flow that is different for PMIP-based S5/S8 interface are shown 
surrounded by shaded box indexed by an upper-case letter in ascending order, e.g. "A", "B", "C", etc. 

For example, at the bottom of the flow, the following text should be included: 

"NOTE: Procedure steps (A) and (B) for an PMIP-based S5/S8 interface are defined in TS 23.402 [2]." 

Further guidance for drafting procedures for TS 23.402 [2] can be found in that specification itself. 
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Annex J (informative): 
High Level ISR description 

J.1 General description of the ISR concept 

Idle state Signalling Reduction (ISR) aims at reducing the frequency of TAU and RAU procedures caused by UEs 
reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially the update signalling 
between UE and network is reduced. But also network internal signalling is reduced. To some extent the reduction of 
network internal signalling is also available when ISR is not used or not activated by the network. 

UMTS described already RAs containing GERAN and UTRAN cells, which also reduces update signalling between UE 
and network. The combination of GERAN and UTRAN into the same RAs implies however common scaling, 
dimensioning and configuration for GERAN and UTRAN (e.g. same RA coverage, same SGSN service area, no 
GERAN or UTRAN only access control, same physical node for GERAN and UTRAN). As an advantage it does not 
require special network interface functionality for the purpose of update signalling reduction. 

ISR enables signalling reduction with separate SGSN and MME and also with independent TAs and RAs. Thereby the 
interdependency is drastically minimized compared with the GERAN/UTRAN RAs. This comes however with ISR 
specific node and interface functionality. SGSN and MME may be implemented together, which reduces some interface 
functions but results also in some dependencies. 

ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. ISR 
requires special functionality in both the UE and the network (i.e. in the SGSN, MME and Serving GW) to activate ISR 
for a UE. For this activation, the MME/SGSN detects whether S-GW supports ISR based on the configuration and 
activates ISR only if the S-GW supports the ISR. The network can decide for ISR activation individually for each UE. 
Gn/Gp SGSNs do not support ISR functionality. No specific HSS functionality is required to support ISR. 

NOTE. A Release 7 HSS needs additional functionality to support the 'dual registration' of MME and SGSN. 

Without such an upgrade, at least PS domain MT Location Services and MT Short Messages are liable to 
fail. 

It is inherent functionality of the MM procedures to enable ISR activation only when the UE is able to register via E- 
UTRAN and via GERAN/UTRAN. For example, when there is no E-UTRAN coverage there will be also no ISR 
activation. Once ISR is activated it remains active until one of the criteria for deactivation in the UE occurs, or until 
SGSN or MME indicate during an update procedure no more the activated ISR, i.e. the ISR status of the UE has to be 
refreshed with every update. 

When ISR is activated this means the UE is registered with both MME and SGSN. Both the SGSN and the MME have a 
control connection with the Serving GW. MME and SGSN are both registered at HSS. The UE stores MM parameters 
from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI and TA(s)) and the UE stores session management 
(bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect 
between E-UTRAN and GERAN/UTRAN (within the registered RA and TAs) without any need to perform TAU or 
RAU procedures with the network. SGSN and MME store each other's address when ISR is activated. 

When ISR is activated and downlink data arrive, the Serving GW initiates paging processes on both SGSN and MME. 
In response to paging or for uplink data transfer the UE performs normal Service Request procedures on the currently 
camped-on RAT without any preceding update signalling (there are however existing scenarios that may require to 
perform a RAU procedure prior to the Service Request even with ISR is activated when GERAN/UTRAN RAs are used 
together, as specified in clause 6.13.1.3 of TS 23.060 [7]). 

The UE and the network run independent periodic update timers for GERAN/UTRAN and for E-UTRAN. When the 
MME or SGSN do not receive periodic updates MME and SGSN may decide independently for implicit detach, which 
removes session management (bearer) contexts from the CN node performing the implicit detach and it removes also 
the related control connection from the Serving GW. Implicit detach by one CN node (either SGSN or MME) 
deactivates ISR in the network. It is deactivated in the UE when the UE cannot perform periodic updates in time. When 
ISR is activated and a periodic updating timer expires the UE starts a Deactivate ISR timer. When this timer expires and 
the UE was not able to perform the required update procedure the UE deactivates ISR. 
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Part of the ISR functionality is also available when ISR is not activated because the MM contexts are stored in UE, 
MME and SGSN also when ISR is not active. This results in some reduced network signalling, which is not available 
for Gn/Gp SGSNs. These SGSNs cannot handle MM and session management contexts separately. Therefore all 
contexts on Gn/Gp SGSNs are deleted when the UE changes to an MME. The MME can keep their MME contexts in 
all scenarios. 



J.2 Usage of the TIN 



The UE may have valid MM parameters both from MME and from SGSN. The "Temporary Identity used in Next 
update" (TIN) is a parameter of the UE's MM context, which identifies the UE identity to be indicated in the next RAU 
Request or TAU Request message. The TIN also identifies the status of ISR activation in the UE. 

The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE sets the TIN when 
receiving an Attach Accept, a TAU Accept or RAU Accept message as specified in table 4.3.5.6-1. 

"ISR Activated" indicated by the RAU/TAU Accept message but the UE not setting the TIN to "RAT-related TMSI" is 
a special situation. Here the UE has deactivated ISR due to special situation handling (see clause J. 6). By maintaining 
the old TIN value the UE remembers to use the RAT TMSI indicated by the TIN when updating with the CN node of 
the other RAT. 

Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all 
registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the 
TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) remain registered with the 
network and valid in the UE. 

When ISR is not active the TIN is always set to the temporary ID belonging to the currently used RAT. This guarantees 
that always the most recent context data are used, which means during inter-RAT changes there is always context 
transfer from the CN node serving the last used RAT. The UE identities, old GUTI IE and additional GUTI IE, 
indicated in the next TAU Request message, and old P-TMSI IE and additional P-TMSI/RAI IE, indicated in the next 
RAU Request message depend on the setting of TIN and are specified in table 4.3.5.6-2. 

The UE indicates also information elements "additional GUTI" or "additional P-TMSI" in the Attach Request, TAU or 
RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new 
MME or SGSN, when the "old GUTI" or "old P-TMSI" indicate values that are mapped from other identities. 



J. 3 ISR activation 



The information flow in Figure J. 3-1 shows an example of ISR activation. For explanatory purposes the figure is 
simplified to show the MM parts only. 

The process starts with an ordinary Attach procedure not requiring any special functionality for support of ISR. The 
Attach however deletes any existing old ISR state information stored in the UE. With the Attach request message, the 
UE sets its TIN to "GUTI". After attach with MME, the UE may perform any interactions via E-UTRAN without 
changing the ISR state. ISR remains deactivated. One or more bearer contexts are activated on MME, Serving GW and 
PDN GW, which is not shown in the figure. 

The first time the UE reselects GERAN or UTRAN it initiates a Routing Area Update. This represents an occasion to 
activate ISR. The TIN indicates "GUTI" so the UE indicates a P-TMSI mapped from a GUTI in the RAU Request. The 
SGSN gets contexts from MME. When the MME sends the context to the SGSN, the MME includes the ISR supported 
indication only if the involved S-GW supports the ISR. After the ISR activated, both CN nodes keep these contexts 
because ISR is being activated. The SGSN establishes a control relation with the Serving GW, which is active in 
parallel to the control connection between MME and Serving GW (not shown in figure). The RAU Accept indicates 
ISR activation to the UE. The UE keeps GUTI and P-TMSI as registered, which the UE memorises by setting the TIN 
to "RAT-related TMSI". The MME and the SGSN are registered in parallel with the HSS. 

After ISR activation, the UE may reselect between E-UTRAN and UTRAN/GERAN without any need for updating the 
network as long as the UE does not move out of the RA/TA(s) registered with the network. 

The network is not required to activate ISR during a RAU or TAU. The network may activate ISR at any RAU or TAU 
that involves the context transfer between an SGSN and an MME. The RAU procedure for this is shown in Figure J. 3-1. 
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ISR activation for a UE, which is already attached to GERAN/UTRAN, with a TAU procedure from E-UTRAN works 
in a very similar way. 



u 
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Figure J.3-1 : ISR Activation example 



J. 4 Downlink data transfer 

Figure J. 4-1 shows a downlink data transfer to an idle state UE when ISR is activated. The Serving GW receives 
downlink data. Because of activated ISR, the Serving GW has control connections with both MME and SGSN and 
sends therefore downlink data notifications to both nodes. MME and SGSN start their paging procedures, which results 
in paging of the UE in the registered RA and TA(s) in parallel. 

In the example illustrated in Figure J.4-1 it is assumed that the UE camps on E-UTRAN. So the UE responds to paging 
as usual with Service Request. This triggers the MME to setup the user plane connection between eNodeB and Serving 
GW. The downlink data are transferred to the UE. 

When the UE camps on UTRAN/GERAN it performs the paging response as specified for these access systems without 
any required update or other signalling before. The downlink data are then transferred via UTRAN/GERAN to the UE. 
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Figure J.4-1 : Downlink data transfer with ISR active 



J. 5 ISR deactivation 



Deactivation of ISR for the UE does not require any specific functionality. The status of ISR activation is refreshed in 
every RAU and TAU Accept message. If there is no explicit indication of ISR Activated in these messages then ISR is 
deactivated and the UE sets its TIN to "GUTI" or "P-TMSI", as specified in Table 4.3.5.6-1. This causes always ISR 
deactivation when a UE performs a RAU with a Gn/Gp SGSN of any standards release as these SGSNs never indicate 
"ISR Activated" to the UE. 



J. 6 Handling of special situations 

Situations may occur that cause unsynchronized state information in the UE, MME and SGSN. Such situations are: 

Modification of any EPS bearer context or PDF context which was activated before the ISR is activated in the 
UE; 

- At the time when the UE moves from E-UTRAN to GERAN/UTRAN or moves from GERAN/UTRAN to E- 
UTRAN, if any EPS bearer context or PDP context activated after the ISR was activated in the UE exists; 

Missing periodic TA or RA updates, e.g. because the coverage of a RAT is lost or the RAT is no more selected 
by the UE (this may result also in implicit detach by SGSN or MME); 

CN node change resulting in context transfer between the same type of CN nodes (SGSN to SGSN or MME to 
MME); 

Serving GW change; 

Change of the UE specific DRX parameters; 

Change of the UE Core Network Capabilities; 

- E-UTRAN selection by a UTRAN-connected UE (e.g. when in URA_PCH to release lu on UTRAN side). 

There are no ISR specific procedures to handle such situations to avoid additional complexity and error cases. All 
special situations that cause context in the UE, MME and SGSN to become asynchronous are handled by ISR 
deactivation. The normal RAU/TAU procedures synchronize contexts in MME and SGSN and activate ISR again when 
wanted by the network. 

Some specific handling is defined to enable combined MME/SGSN. For this the UE signals at UTRAN RRC level 
always an Intra Domain NAS Node Selector (IDNNS) derived from the ID signalled as P-TMSI (also when mapped 
from GUTI). At E-UTRAN RRC level the UE indicates the GUMMEI derived from the GUTI that is signalled in the 
TAU Request message (also when derived from P-TMSI). This handling is performed by the UE independent from the 
network configuration. It is not visible to the UE whether MME and SGSN are combined. 
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Given the IP-based architecture of EPS and the IP-based applications such establishment and deactivation of the EPS 
bearer or PDP context can happen frequently before the UE changes the RAT e.g. a UE asking for delivery of an SMS 
(over IP) or starting a VoIP over IMS, an entirely new EPS bearer or PDP context may be established for that purpose. 
Then, after the application/service is finished, the newly established EPS bearer or PDP context gets deactivated. In 
such particular situation the deactivation of the ISR at the UE and hence performing a RAU or TAU update when the 
UE changes the RAT is not needed. Preventing the UE from deactivating the ISR in this case ensures an efficient usage 
of the UE's battery power and reduces the unnecessary signalling load that is seen as the key objective to be achieved by 
introducing the ISR feature. Thus, UE only locally deactivates ISR when bearer existed at the time of ISR is activated, 
or when UE changes RAT with bearers which are created after ISR is activated. 
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Annex K (informative): 
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